Pre-allocate trunk's VERSION_SHORT after release - #25876
Draft
mokagio wants to merge 2 commits into
Draft
Conversation
Phase 1 of Jeremy Massel's Faster Releases RFC added per-commit trunk TestFlight builds (#25674), but explicitly deferred the version pre-allocation piece ("VERSION_SHORT left as-is... deferred to go-live"). Without it, trunk keeps the just-shipped VERSION_SHORT until the next code freeze, and any trunk TestFlight upload in that window is rejected by `altool` once Apple closes that version's pre-release train — as happened on trunk starting build #33637. `create_backmerge_pr` gains a `pre_allocate_trunk_version` option, wired up only from `finalize_release` (never `finalize_hotfix_release`, since a hotfix doesn't own trunk's currently-open line). It uses the `create_release_backmerge_pull_request` action's existing `intermediate_branch_created_callback` hook to bump trunk's `VERSION_SHORT` to the next release version as part of the backmerge, instead of letting the merge carry back the release branch's now-closed version. `code_freeze` now reads that pre-allocated value directly (`release_version_current`) instead of deriving `+1` from it (`release_version_next`) — otherwise the next freeze would derive one version too many and silently skip a release number. RFC: https://wpmobilep2.wordpress.com/2026/05/13/rfc-faster-releases-for-wordpress-and-jetpack/ --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
27.1 shipped and Apple closed its pre-release train, so every trunk TestFlight upload since has failed with "Invalid Pre-Release Train" (`altool`). This one-time bump seeds the pre-allocation invariant just added in the previous commit for a version that shipped before it existed. Only safe together with that commit: without the `code_freeze` change there, the next freeze would derive `27.3` from this value and skip `27.2` as an actual release. --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Collaborator
Generated by 🚫 Danger |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@jkmassel @crazytonyli my research agent flagged that
trunk's CI has been read since TIME. I asked it to investigated and it concluded is due to 27.1 having been marked as a closed track in ASC andtrunkstill trying to upload 27.1 builds. We knew this was going to happen when we decided to update the release cycle model. This PR implements what it thought to be the best implementation of the next steps as discussed in the RFC. Hope it helps you get started.Rationale
Trunk's TestFlight-upload step has been red since build #33637:
altoolrejects the upload withInvalid Pre-Release Train. The train version '27.1' is closed for new build submissions. 27.1 shipped and Apple closed that train; trunk'sVersion.public.xcconfigstill points at it because nothing bumps it between a release shipping and the next code freeze.This gap is the deferred half of the RFC for faster releases pbArwn-7YT-p2. Phase 1 (#25674) added the per-commit trunk TestFlight builds; the RFC's version pre-allocation ("after 26.8 ships, the version is immediately bumped to 26.9") was explicitly deferred at the time. This PR implements that piece:
finalize_release's backmerge now pre-allocates trunk'sVERSION_SHORTto the next release, andcode_freezereads that value directly instead of deriving+1from it.Intentional tradeoffs
finalize_releasetriggers the pre-allocation bump —finalize_hotfix_releasedeliberately doesn't, since a hotfix ships off a tag and doesn't own trunk's currently-open line.create_release_backmerge_pull_request's existingintermediate_branch_created_callback— no changes to the sharedwpmreleasetoolkitgem action.27.2to seed the invariant for the version that already shipped without it — that's what actually turns the failing step green.Gotchas
release.rbchanges are coupled: shipping thecode_freezechange without the backmerge change leaves trunk stuck on the closed train; shipping the backmerge change without thecode_freezechange makes the next freeze derive one version too many and silently skip a release number. They're one commit for that reason.finalize_release's backmerge against real GitHub/App Store Connect locally, so this is unverified end-to-end — flagging that explicitly rather than claiming it's tested. Marking as draft for that reason, and because it changes core release-pipeline semantics that should get your eyes given you own the RFC.How to test
ruby -c fastlane/lanes/release.rbandbundle exec rubocop fastlane/lanes/release.rbboth pass.fastlane-plugin-wpmreleasetoolkitsource (IOSVersionFile#write,MarketingVersionCalculator#next_release_version,CreateReleaseBackmergePullRequestAction's callback contract) rather than guessed.code_freeze→finalize_releasecycle; happy to pair on that when we're ready to try it, or walk through the mechanism first if you'd rather review the design before it runs for real.