[Tooling] Make beta releases self-contained with translations and backmerge

[iangmaia]

Relates to AINFRA-2108

Related issues

• Related to [Tooling] Add Buildkite release pipelines and fastlane lanes for ReleasesV2 #2583
• wpcom PR: https://github.a8c.com/Automattic/wpcom/pull/205520

Proposed Changes

• code_freeze lane: No longer triggers the first beta. Now only creates the release branch, extracts translatable strings, generates draft release notes, and creates a backmerge PR. The first beta is triggered manually via ReleasesV2.
• new_beta_release lane: Now self-contained — downloads latest translations from GlotPress, bumps the version, triggers the build, and creates a backmerge PR. Added github_username parameter for backmerge PR reviewer.
• Removed download_translations lane and pipeline: Translations are now downloaded as part of each beta release. The standalone fetch_glotpress_translations lane remains available for manual use.
• Updated docs: release-process.md and localization.md reflect the new flow.
• Updated pipeline YAMLs: new-beta-release.yml now passes github_username, download-translations.yml deleted.

Companion wpcom PR needed for scenario file updates (wpstudio.php).

Testing Instructions

• Review the Fastfile changes for correctness
• Verify the code freeze and beta release flows match the updated documentation

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[AliSoftware]

⚠️ ❓ Does the removal of this step means that if a release have it's first beta on the same day as the code freeze… but then no additional beta for the rest of the release (because no bugs was found during beta-testing), we won't download the latest translations during release finalization and might thus miss the opportunity to get more recent translations that had been translated by translators post-code-freeze while the app was in beta?!

I'd suggest to always download the latest translations at the time of release finalization scenario phase milestone (or the day before, like we do for Tumblr) to ensure that they get downloaded late in the release cycle and thus give the most time for translators to translate as much as possible.

[iangmaia]

That's a good point -- the previous implementation, at the "Pre-Release" stage, wasn't fully in line with the process either. Running a final fetch during finalize release makes total sense 👍

[iangmaia]

Updated on f4ccc01.

[AliSoftware]

Note that this means that code-freeze will create one backmerge PR (to commit the version bump + extracted translatable strings etc), then on the step close after that in the scenario, we will separately trigger the first new_beta_release… which will also create yet another backmerge PR (whose diff this time will mostly only contain the beta version bump and not much else), right?

I'm OK with that if that's acknowledged, but just wanted to highlight that side effect of the separation, since that now means 2 backmerge PRs close to one another instead of a single one (and means waiting for CI to go green on each of those… but for that we can improve the RMs life via pr_changed_files-based filtering to reduce the number of CI jobs to run and having to wait for especially on the 2nd PR I guess)

[iangmaia]

Yeah, good point, I discussed this a bit with @sejas. I like the fact that we'll have backmerge PRs for each beta + download translations and I think that's the main point I wanted to address after the discussions.

But one point I'm not totally convinced about is the need (or not) of the "automatic" first beta build during code freeze (which could create the first backmerge instead of having it both on code freeze + first beta). The implementation removed it, but on a second thought I think having it saves a couple of clicks and binds the release process together a bit more. 🤷

[AliSoftware]

Another option would be to remove the backmerge PR at the time of code_freeze, relying on the fact that a new_beta_release will be triggered afterwards as a separate step in the release scenario.

Thinking about it, this is kinda what we do in some other product repos that need a pause between the start of the code freeze and the first beta (e.g. DOAndroid)… except in those repos we've used the convention to have a lane named complete_code_freeze for the similar case.
I'm ok to not have a lane called complete_code_freeze here if all it does in the case of Studio is doing the exact same as just calling new_beta_release directly and nothing more btw. Just drawing parallels.

This also re-enforces my suggestion on the ReleasesV2 PR (205520-ghe-Automattic/wpcom#discussion_r201295) that this step to create the first beta post code-freeze, even if it's now on demand and not done as part of the code_freeze lane, should still be a Task that already exists in the scenario from scratch when the scenario is created, instead of relying on the Release Manager having to remember to click the "New Beta" button manually.

[EDIT] At the time I wrote this comment I hadn't seen your intermediate reply (as I hadn't refreshed the GitHub page) [/EDIT]

[iangmaia]

One important point about the Code Freeze backmerge is the .pot file update, so that's the main reason I kept the backmerge.

[AliSoftware]

Yeah but if we're guaranteed to have a beta being done as a follow up step after the backmerge (be it because the code_freeze lane calls the new_beta_release lane itself or because we have a 'Task::buildkitein the scenario to trigger bynew_beta_releasewhen ready at the end of theMilestone::code_freeze), then that backmerge PR that is going to be created as part of that first beta will also contain the change to the .pot`. So that would just lead to one (not so) big PR containing everything, instead of 2 smaller ones back to back.

[AliSoftware]

By the way, tangentially related, one small bug we found in the first release was that, if we do an automated (or separate task, for that matter) first beta, the second beta created using "Add Beta" button will still say Beta Release 1 😄 not sure if this came up in other apps, but in Studio this became more visible as the increment is part of the version used everywhere.

I think this has always been the case even in other products? And probably part of why we've been calling the betas added via the button as "Intermediate beta" (as a cheat to suggest that there's the first beta made during code freeze, then a first intermediate beta after that, etc) 😅

So even in other products where we use different naming conventions of where we do the first beta as part of the code freeze lane this is also the case (eg first beta done during code freeze is named -rc-1 and Intermediate Beta 1 makes this bumped to -rc-2)

[AliSoftware]

Random example with PockatCasts Android:

• Code Freeze does the version bump then builds a beta, which results in app-8.6-rc-1.apk
• Intermediate Beta 1 triggers a build which bumps the version to 8.6-rc-2

So that off-by-one in the title has always been there.

Maybe if we renamed the task in Releases V2 from "Intermediate Beta 1" to "Intermediate Bugfix build 1" to make the distinction even clearer between "the first build done during code freeze" vs "subsequent beta builds that are only done if we found a bug and merged a fix and want to do a new beta to include that bugfix". But at that point I think that'd be wayyy too nitpicky 😄

Besides, there is also the seldom but possible case that a failed beta build would need to be retried and end up bumping the version number multiple times (see the case we had this morning with DOAndroid — p1772201201312009-slack-C06CKSPHYA1) which would lead to the version being -rc-2 at the end of the code freeze, and the "Intermediate Beta 1" would then produce an -rc-3 😛

So in the end I think we don't need to be too much attached with this off-by-one offset between "Intermediate Beta" index and -betaN version name?

[sejas]

Would it be possible to separate the pots generation and the submission of strings to GlotPress from the code freeze milestone?

• Day 1: Submit strings (Back merge)
• Day 3: Produce Beta1 (Codefreeze + beta + backmerge)
• Day 3+: Produce more betas manually + backmerge
• Day 5 : Build release
• Day 8: Publish release

[sejas]

We decided p1772217237435699/1771256551.851819-slack-C06DRMD6VPZ to produce the code freeze and then a different milestone to produce a new beta1 a couple of days later. We always can iterate in these decisions after trying the real process a couple of cycles.

[AliSoftware]

So if I understand the discussion from Slack correctly, that will be:

• Day 1: Freeze the code and the associated strings (i.e. Code Freeze to create the release branch and generate the pot then backmerge to trunk so that the strings are uploaded to GlotPress)
• Day 3: Produce Beta1 (new beta build + backmerge)
• Day 3+: Produce more betas manually + backmerge
• Day 5 : Build release
• Day 8: Publish release

If so, then that sounds good to me 👍