CLDR-18279 Generate cldr-json 47.0.0-ALPHA2

[btangmu]

-Built with cldr tags/release-47-alpha2

-Built with cldr-staging tags/release-47-alpha2 (downloaded as cldr-staging-release-47-alpha2.tar.gz)

[srl295]

• seems unrelated to CLDR-18245 Generate cldr-json 47.0.0-ALPHA1 and ALPHA2 #81 or CLDR-18245 Generate cldr-json 47.0.0-ALPHA1 #80 ? could just add commits to the same branch. Otherwise it's hard to see what's different between alpha1 and alpha2

[btangmu]

• could just add commits to the same branch

OK, I've done that. See the 2nd commit on #81

There are a lot of differences of procedure between cldr and cldr-json, in terms of how we use tickets, PRs, and release tags. It's starting to make sense... Next time, I guess I would not make separate tickets or branches or PRs for alpha1/alpha2/beta1/beta2/... How about release candidates, should those stay on the same ticket/branch/PR, until finally getting merged into main?

[srl295]

• could just add commits to the same branch

OK, I've done that. See the 2nd commit on #81

There are a lot of differences of procedure between cldr and cldr-json, in terms of how we use tickets, PRs, and release tags.

it's a data repo, so it's a lot more like cldr-staging in that regard.

It's starting to make sense... Next time, I guess I would not make separate tickets or branches or PRs for alpha1/alpha2/beta1/beta2/... How about release candidates, should those stay on the same ticket/branch/PR, until finally getting merged into main?

I usually make one PR and branch for (and named) say v44 and keep updating that, tagging from it, and then merge it into main on release.

That way , the PR shows 'what changed' since the previous version, and each commit shows what changed in the different alpha/beta tags.