Bump to 4.2.7 for release - #28
Closed
Robbie1977 wants to merge 2 commits into
Closed
Conversation
The release-tag assertion added in #23 fails a v* build when package.json disagrees with the tag, so the bump has to land before the tag is cut. That is the guard working as intended: v4.2.3 shipped reading 4.2.2 and reported itself as 4.2.2 while being entirely correct, which is indistinguishable from a failed rollout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
|
Superseded by #29, which lands the mechanism this was working around. The tag is now the source of truth: CI reads the version off it, applies it to every file in RELEASE_SURFACES, builds from that tree and pushes the result back to main. A hand-written bump commit is no longer part of cutting a release, so this branch has nothing left to do. The battery results it carried are already on main in b934102. Closing, and deleting release/4.2.7. |
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
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.
The release-tag assertion added in #23 fails a
v*build whenpackage.jsondisagrees with the tag, so the bump lands before the tag is cut.That is the guard working as intended. v4.2.3 shipped with
package.jsonreading4.2.2and reported itself as4.2.2while being entirely correct and correctly deployed — indistinguishable from a failed rollout, and roughly an hour was spent chasing a pull that had in fact worked.Note
APP_VERSIONis deliberately empty on a branch push, sopackage.jsonremains the fallback everywhere except a tagged release build. A stale version in the repo is not cosmetic: it is what dev and branch builds report, and it is what anything reading the repository sees.