Add pre-release version batching to VersionCheck and Registrator#110
Merged
Add pre-release version batching to VersionCheck and Registrator#110
Conversation
Lets a package accumulate multiple breaking-change PRs against `main` under a stable pre-release suffix (e.g. `0.22.0-DEV`) and register a single release at the end. While the version carries any pre-release suffix, VersionCheck allows successive PRs to leave the version unchanged and Registrator skips registration entirely. The eventual strip-suffix release PR (`0.22.0-DEV` -> `0.22.0`) registers normally. Also adds bump-shape validation pre-merge in VersionCheck. Previously the shape check (patch+1, minor+1 with patch=0, major+1 with minor=patch=0) ran only post-merge in Registrator, so a malformed bump like `0.21.5 -> 0.99.0-DEV` would only be caught after the PR landed. Both workflows now share a `valid_bump` function with a "keep in sync" comment. On the strip-suffix release PR, `is_breaking` is now determined against the last actually-released version in the branch's history rather than the previous (pre-release) commit, which would otherwise mis-classify the release as non-breaking. Incidental cleanup: extract the duplicated General-vs-local registry lookup into a `register_route` helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mtfishman
added a commit
to ITensor/ITensorTestPackage.jl
that referenced
this pull request
May 8, 2026
## Summary End-to-end canary for the prerelease-batching feature merged in [ITensor/ITensorActions#110](ITensor/ITensorActions#110): exercise the strip-suffix release path. Expected behavior on this PR: - **VersionCheck (pre-merge):** pass. `0.2.0-DEV → 0.2.0` is the documented release transition. - **Registrator (post-merge):** fire and open a registry PR against `ITensorRegistry` for `ITensorTestPackage v0.2.0`. - **`is_breaking`:** derived against the last released version (`0.1.0`) via `find_last_released_version`, since `0.2.0-DEV` shares the bare `M.m.p` with this release. With `0.1.0` as the reference, this is a pre-1.0 minor bump → breaking → release notes propagate to the registry PR and the GitHub release. - **TagBot:** auto-fires after the registry PR merges, creating `v0.2.0` tag and release. Release notes: > Canary release validating the prerelease-batching workflow end-to-end. No package functionality changed between 0.1.0 and 0.2.0.
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
Lets a package accumulate multiple breaking-change PRs against
mainunder a stable pre-release suffix (e.g.0.22.0-DEV) and register a single release at the end. While the version carries any pre-release suffix,VersionCheckallows successive PRs to leave the version unchanged andRegistratorskips registration entirely. The eventual strip-suffix release PR (0.22.0-DEV->0.22.0) registers normally.Workflow
0.21.50.22.0-DEV0.22.0-DEV0.22.0-DEV0.22.0-DEV0.22.0is_breakingdetermined against last released versionSuffix is freeform (
-DEV,-rc,-alpha, etc.); any non-empty pre-release tag triggers the skip behavior. The convention in the ITensor ecosystem will be-DEVto match Julia's own nightly versioning.Bump-shape validation moved pre-merge
Previously the shape check (patch+1, minor+1 with patch=0, major+1 with minor=patch=0) ran only post-merge in
Registrator, so a malformed bump like0.21.5 -> 0.99.0-DEVor0.21.5 -> 0.21.7would only fail after the PR landed.VersionChecknow runs the samevalid_bumpcheck pre-merge so malformed bumps fail the PR check directly.valid_bumpis duplicated betweenVersionCheck.ymlandRegistrator.ymlwith a "keep in sync" comment — the two reusable workflows can't easily share Julia code without a heavier composite-action setup. If maintenance becomes painful, we can lift it into a shared composite action later.is_breakingon the release PRThe strip-suffix release PR (
0.22.0-DEV->0.22.0) sharesM.m.pwith the previous commit, which would mis-classify the release as non-breaking under the existing major-or-minor-bump rule. A newfind_last_released_versionhelper walks the branch's history to find the most recent suffix-free version and computesis_breakingagainst that.Incidental cleanup
The General-vs-local registry-route lookup was duplicated in two branches of the
Registratormeta step. Extracted into aregister_route(uuid)helper.