docs/ci: document the dev/YYYY -> maint/YYYY branch strategy and align the release workflow with it - #145
Merged
Conversation
Branch naming and roles were never written down, which led to inconsistent conventions across long-lived branches (e.g. maintenance2023 and maintenance2026 predate this and were named for the calendar year they were forked, not the fiscal-year dev cycle they continue). Going forward: - dev/YYYY is the active development branch for fiscal year YYYY. - once its cycle is done, it is merged into main and renamed in place to maint/YYYY (not re-created), becoming hotfix-only. - from that rename until the next dev/YYYY+1 exists, hotfixes target the current maint/YYYY, not main directly. - both dev/YYYY and maint/YYYY are protected: PR-only, no direct commits. - main only moves forward at a release cut (dev/YYYY merge, or a maint/YYYY hotfix line merged forward for a patch release). - maintenance2023/maintenance2026 are grandfathered as-is. Also add a one-line pointer in AGENTS.md so this is followed strictly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
…anch strategy - Only trigger on merged PRs targeting main, maint/**, or dev/** - previously pull_request_target had no branches filter at all, so every merged PR to every branch in the repo (including short-lived fix/*/docs/* branches) produced a full ~1.4GB release (wheel.sif + wheel_docker.tar.gz + source.tar.gz). This is the root cause of the recent release-artifact pile-up (24 GitHub Releases, most from routine PR merges rather than deliberate release points). - Add SAFE_BRANCH_NAME (BRANCH_NAME with "/" stripped) and use it for the Docker tag and source tarball's top-level directory name - dev/YYYY and maint/YYYY contain a slash, which a Docker tag cannot. - Classify dev/* as beta (previously fell through to the generic "else" case) and maint/* as maintenance (dropping the old flat maintenance* compat pattern - maintenance2023/maintenance2026 run their own independently-committed copy of this workflow file via pull_request_target, so this change has no effect on them either way). - Give each release type a distinct, immediately visible title prefix (no native GitHub Release mechanism distinguishes more than prerelease/latest/draft, so this is convention-based): - release (main): "✅ Release ..." - maintenance (maint/YYYY): "🔧 Maintenance ..." - beta (dev/YYYY): "🧪 Beta ..." - maintenance releases are real (non-prerelease) releases - they are genuine backport fixes, not experimental builds - but never take the "Latest" badge/redirect; only main does. Only beta is marked prerelease. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
This was referenced Sep 22, 2026
so5
added a commit
that referenced
this pull request
Sep 22, 2026
…rategy work) Bring maintenance2026's build_and_deploy.yml in line with main's release labeling scheme (see #145): each release type gets a distinct title prefix (release/maintenance/beta - unreachable "release" and "beta" cases kept only for parity with main's copy, since this branch's own name always resolves to TYPE=maintenance), and maintenance releases are real (non-prerelease) releases that never take the "Latest" badge - previously every non-master build was marked prerelease regardless of type. Also carries over SAFE_BRANCH_NAME (BRANCH_NAME with "/" stripped) for consistency with main's copy, even though this branch's own name has no slash to strip. Trigger (workflow_dispatch only) is unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
so5
added a commit
that referenced
this pull request
Sep 22, 2026
…rategy work) Bring maintenance2023's build_and_deploy.yml in line with main's release labeling scheme (see #145): each release type gets a distinct title prefix (release/maintenance/beta - unreachable "release" and "beta" cases kept only for parity with main's copy, since this branch's own name always resolves to TYPE=maintenance), and maintenance releases are real (non-prerelease) releases that never take the "Latest" badge - previously every non-master build was marked prerelease regardless of type. Also carries over SAFE_BRANCH_NAME (BRANCH_NAME with "/" stripped) for consistency with main's copy, even though this branch's own name has no slash to strip. Trigger (workflow_dispatch only) is unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu
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
1 participant
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.
Summary
Branch naming and roles were never written down, which led to inconsistent conventions across long-lived branches (
maintenance2023andmaintenance2026were named for the calendar year they were forked, not the fiscal-year dev cycle they continue), and the release workflow was producing a full release for every merged PR to any branch.Changes
Branch strategy (README.md "For developpers" -> "Branch strategy", AGENTS.md)
dev/YYYY: active development branch for fiscal year YYYY.mainand renamed in place tomaint/YYYY(hotfix-only).dev/YYYY+1exists, hotfixes target the currentmaint/YYYY, notmaindirectly.dev/YYYYandmaint/YYYYare PR-only (no direct commits).maintenance2023/maintenance2026predate this rule and are kept as-is.Release workflow (
.github/workflows/build_and_deploy.yml)pull_request_targetnow only fires for merged PRs targetingmain,maint/**ordev/**. Previously there was nobranchesfilter, so every merged PR to every branch produced a full ~1.4GB release (wheel.sif+wheel_docker.tar.gz+source.tar.gz) - the cause of the recent release pile-up.SAFE_BRANCH_NAME(BRANCH_NAMEwith/stripped) is used for the Docker tag and the source tarball's top-level directory, sincedev/YYYY/maint/YYYYcontain a slash a Docker tag cannot.main-> release,maint/*-> maintenance,dev/*-> beta. Each gets a distinct title prefix (✅ Release/🔧 Maintenance/🧪 Beta), since GitHub Releases has no native mechanism beyond prerelease/latest/draft.maintakes the "Latest" badge. Maintenance releases are regular (non-prerelease) releases that never become "Latest"; only beta is marked prerelease.maintenance*pattern is dropped:maintenance2023/maintenance2026run their own independently-committed copy of this workflow (pull_request_targetuses the base branch's workflow file), so this change does not affect them.Notes
pull_request_targetruns the workflow file from the base branch, merging this PR itself will still run the old workflow once (one last release).maintenance2023/maintenance2026are later moved undermaint/, their own copy ofbuild_and_deploy.ymlneeds to be updated separately (a rename alone does not change it).🤖 Generated with Claude Code
https://claude.ai/code/session_01C3jKNM1qubomM8UTRdkEWu