Improve releaseWizard's logchange.py to handle LTS release#4425
Merged
Conversation
Address copilot review comments
Contributor
Author
|
Some tweaks after more simulation. Here is the summary for the last simulation run I did locally using the |
janhoy
added a commit
that referenced
this pull request
May 13, 2026
(cherry picked from commit 7a0a004)
janhoy
added a commit
that referenced
this pull request
May 13, 2026
(cherry picked from commit 7a0a004)
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.
This PR improves
logchange.pyand the release wizard to handle two scenarios:LTS release support in
forward-port: A new--latest-lts-stable-branchargument causes changelog commits to also be forward-ported to the LTS stable branch (e.g.branch_9x) when releasing from a major-version branch that is the current LTS line.CHANGELOG.mdandversion-summary.mdare never cherry-picked — they are always regenerated fresh on each target branch to avoid cross-major-version conflicts.RC-number labelling in
prepare: A new--rc-numberargument (default: 1) appendsRC<n>to commit messages for RC2+ releases.Atomic two-commit workflow (both
prepareandforward-port): the YAML/date-file changes are committed first (commit A), thenlogchangeGenerateruns and its output (CHANGELOG.md+version-summary.md) is committed separately (commit B). This avoids staging stale generated files alongside source YAML.The release wizard is updated to expose
is_lts_releaseandlatest_lts_stable_branchin Jinja context and to conditionally pass the new flags in the rendered shell commands.Testing
Tested with a shell simulation simulate.sh (gist) that replays a full realistic multi-branch release sequence in an isolated local repo:
v9.10.0(onbranch_9x+main) andv10.0.0(onmain/branch_10x) already released.prepareandforward-portwith the appropriate branchtopology.
--latest-lts-stable-branch branch_9x; non-LTS releases omit it.mainwith the correct YAML files, no conflicts, andchangelog/unreleased/contains only.gitkeep.