[heifner]

Lets a release/<major>.<minor> branch carry its own releases (1.1.0-rc1, 1.1.0, 1.1.1, …) while master moves on. Until now prepare-release.yaml and tag-release.yaml only worked on master, release.yaml refused any tag not on master, and PRs into any other branch ran no checks.

• prepare-release.yaml and tag-release.yaml take a branch input, default master. A release branch takes only its own line's versions, and master refuses a version whose release/<major>.<minor> branch already exists.
• Both keep master at the workspace root. Its cmake-version.py validates the inputs and reads or writes the target branch, which is checked out as refs/heads/<branch> into target/ (without credentials in tag-release.yaml). No code from the target branch runs.
• tag-release.yaml refuses a branch whose rules have no pull_request rule. prepare-release.yaml refuses to force-push a prep branch whose open PR targets another branch.
• release.yaml accepts a tag that sits on master or on its version's release/<major>.<minor> branch. The branch name is derived inline, because the job runs the tag's own copy of the parser.
• release.yaml gives the latest label to the highest published stable version, and hands it back if a hand-published older release took it. Publishing and the label run in a publish-release job queued across every tag, so releases published together cannot leave the label on the lower version.
• PRs into release/* run the same checks as PRs into master, and release/prep-* pushes build nothing.
• A new release-tooling job, which All Required Tests Passed waits for, runs the unit tests for cmake-version.py in .github/scripts/test_cmake_version.py. It also fails a PR that changes its base branch's version, unless it is that version's release/prep-v<version> bump PR onto a branch that may carry it. Without that, merging release/1.1 forward into master can carry release/1.1's version with no conflict: master at 1.2.0-dev plus release/1.1 going 1.1.0-dev to 1.1.0 gives master 1.2.0.
• cmake-version.py refuses a CMakeLists.txt with more than one set(VERSION_*) line, so unresolved conflict markers fail instead of reading as one side's version. It also names the bump branch for both prepare-release.yaml and the PR check, and has the highest-tag mode wire-sysio's tag build uses to pick its wire-cdt release.
• docs/release-workflow.md documents release branches, how a PR into one is merged forward to master, and the post-bump after a stable release: master to its next -dev version, a release branch to its next patch's (1.1.0 to 1.1.1-dev).

Before the first release from release/1.1:

• release/* needs the same branch ruleset as master, excluding release/prep-*. Until then tag-release.yaml refuses the branch.
• Cut release/1.1 from master once this merges and master holds what 1.1 ships (the early cut was deleted), so it carries these workflow files.

wire-sysio gets the same change in its own PR.

[huangminghuang]

Reviewed current head 59ec0031c3e79d4e541907507be1acca7440f95d. One actionable finding:

[P2 / Medium] Serialize latest updates across releases — .github/workflows/release.yaml:253–258.

Concurrency is scoped per tag, so different versions can publish simultaneously. If v1.1.1 lists releases before v1.2.0 publishes, it retains --latest and can overwrite the newer release’s label after uploading its assets. I reproduced this with the exact publish script and mocked GitHub calls: both releases were published, but latest ended at v1.1.1. Serialize the release-list, publication, and latest-label updates with a repository-wide publishing lock.

Validation: all 33 Python tests passed; actionlint passed for all five changed workflows.

[heifner]

Thanks, fixed in 71fe87a. The per-tag job is now attach-assets (verify, checksums, upload, and on the hand-pushed-tag fallback it creates the draft). Publishing and the label moved to a publish-release job whose concurrency group, publish-releases, is shared by every tag. queue: max makes a third release waiting behind two others queue up instead of replacing the pending one. Run one after another against a stateful gh stand-in, in both orders and with the label previously taken by a hand-published release, the label always ended on the highest stable release.

actionlint, including its latest release 1.7.12, still rejects queue: that release predates the May 2026 feature. GitHub's workflow schema in actions/languageservices accepts queue: single|max on job-level concurrency. Neither repo runs actionlint in CI.

[huangminghuang]

Reviewed 71fe87a. No new actionable findings. The previously reported latest-label race is addressed by the shared publishing queue. All 41 parser tests and five mocked publication scenarios passed.