-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore/build: Teach JetBrains push-git-tag-for-next-release.sh about release branches #6881
Merged
Conversation
This file contains 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
abeatrix
approved these changes
Jan 30, 2025
dominiccooney
added a commit
that referenced
this pull request
Jan 30, 2025
…ease.sh about release branches (#6884) These scripts predate release branches and used to always look at global tags. This change makes it work on release branches. It uses git to list the commits on the release branch, then does the same version bump calculation using the branch's tags. It takes care to handle newly budding branches which are just a commit on `main` that has no backports yet. In that case it looks at all of the available tags. It will work carrying a branch from prerelease through to release: ``` # At the start of the branch $ ./scripts/push-git-tag-for-next-release.sh --minor --nightly # During prerelease, assume we have accumulated some commits on the branch now: $ ./scripts/push-git-tag-for-next-release.sh --patch --nightly # Transitioning to release: $ ./scripts/push-git-tag-for-next-release.sh --minor # Hopefully never needed, but making emergency patches on stable: $ ./scripts/push-git-tag-for-next-release.sh --patch ``` There are some caveats with this tool: - When working on a release branch, it only has *local* view of *that branch's tags.* Misusing it should be harmless because creating a tag which conflicts with an existing tag will fail when the tag is pushed. - It does not enforce the new practice of stable builds having even version numbers and prerelease builds having odd version numbers. If you ever need to work around this tool, just author and push git tags yourself. To this point release captains have been doing that anyway. Adds a `--dry-run` option which makes testing easier. Removes outdated docs and points to Notion instead. ## Test plan ``` # Pretend you're just cooking up a release branch $ git remote update origin $ git checkout -b my-release-branch origin/main $ cd jetbrains $ ./scripts/push-git-tag-for-next-release.sh --minor --nightly --dry-run # It should suggest a minor version bump based on all the version tags in the repo ... # Pretend you're on a release branch, we're doing a patch release $ git fetch origin refs/heads/jb-v7.8.x $ git checkout FETCH_HEAD $ git checkout <this PR> -- scripts/next-release.sh scripts/push-git-tag-for-next-release.sh $ git commit -m 'test test test do not push' # script insists the repo is clean $ ./scripts/push-git-tag-for-next-release.sh --minor --dry-run # It should suggest v7.8.1 ``` I am the release captain and will dogfood this script in the current release. <br> Backport b912145 from #6881 Co-authored-by: Dominic Cooney <[email protected]>
taiyab
pushed a commit
that referenced
this pull request
Feb 3, 2025
…elease branches (#6881) These scripts predate release branches and used to always look at global tags. This change makes it work on release branches. It uses git to list the commits on the release branch, then does the same version bump calculation using the branch's tags. It takes care to handle newly budding branches which are just a commit on `main` that has no backports yet. In that case it looks at all of the available tags. It will work carrying a branch from prerelease through to release: ``` # At the start of the branch $ ./scripts/push-git-tag-for-next-release.sh --minor --nightly # During prerelease, assume we have accumulated some commits on the branch now: $ ./scripts/push-git-tag-for-next-release.sh --patch --nightly # Transitioning to release: $ ./scripts/push-git-tag-for-next-release.sh --minor # Hopefully never needed, but making emergency patches on stable: $ ./scripts/push-git-tag-for-next-release.sh --patch ``` There are some caveats with this tool: - When working on a release branch, it only has *local* view of *that branch's tags.* Misusing it should be harmless because creating a tag which conflicts with an existing tag will fail when the tag is pushed. - It does not enforce the new practice of stable builds having even version numbers and prerelease builds having odd version numbers. If you ever need to work around this tool, just author and push git tags yourself. To this point release captains have been doing that anyway. Adds a `--dry-run` option which makes testing easier. Removes outdated docs and points to Notion instead. ## Test plan ``` # Pretend you're just cooking up a release branch $ git remote update origin $ git checkout -b my-release-branch origin/main $ cd jetbrains $ ./scripts/push-git-tag-for-next-release.sh --minor --nightly --dry-run # It should suggest a minor version bump based on all the version tags in the repo ... # Pretend you're on a release branch, we're doing a patch release $ git fetch origin refs/heads/jb-v7.8.x $ git checkout FETCH_HEAD $ git checkout <this PR> -- scripts/next-release.sh scripts/push-git-tag-for-next-release.sh $ git commit -m 'test test test do not push' # script insists the repo is clean $ ./scripts/push-git-tag-for-next-release.sh --minor --dry-run # It should suggest v7.8.1 ``` I am the release captain and will dogfood this script in the current release.
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.
These scripts predate release branches and used to always look at global tags. This change makes it work on release branches. It uses git to list the commits on the release branch, then does the same version bump calculation using the branch's tags.
It takes care to handle newly budding branches which are just a commit on
main
that has no backports yet. In that case it looks at all of the available tags.It will work carrying a branch from prerelease through to release:
There are some caveats with this tool:
If you ever need to work around this tool, just author and push git tags yourself. To this point release captains have been doing that anyway.
Adds a
--dry-run
option which makes testing easier. Removes outdated docs and points to Notion instead.Test plan
I am the release captain and will dogfood this script in the current release.