build: make git tags the source of truth for release version#318
Merged
Conversation
pbr now derives the package version from git tags (prior commit), so setup.cfg no longer needs VERSION written into it -- the only place VERSION was still required by hand was `make release`. The value was already sitting at the top of CHANGES.txt (the "X.Y.Z (unreleased)" heading written by the previous release's post-release bump), so read it from there and only fall back to requiring an explicit VERSION= when that heading is missing. Also drops the "dev" suffix from the bumped heading (e.g. "2.4.2 (unreleased)" instead of "2.4.2dev (unreleased)") so the auto-detected value is a clean version the awk can pass straight to `git tag` without stripping it first. Verified with `make -n release-tag` (auto-detects 2.4.1, computes next version 2.4.2) and `make -n release-tag VERSION=9.9.9` (override still wins). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…S.txt The previous commit read VERSION from CHANGES.txt's "(unreleased)" heading -- a second, hand-maintained copy of the version that can drift from what pbr actually derives from git tags, and gave pbr no way to signal a minor/major bump (it only ever auto-advances the patch). release-tag now reads VERSION from `python setup.py --version` (pbr's own git-tag-derived version), stripped to the leading X.Y.Z. It rewrites CHANGES.txt's heading with the actual released version + date rather than assuming the heading already had the right number, since CHANGES.txt is a downstream record now, not an input. Add bump-version: tags vM.m.p.0a1, pbr's pre-release marker, which locks every untagged build to that target version (as M.m.p.0a<N>.dev<commits>) until the real vM.m.p tag lands. This is the explicit human step for a minor/major release; patch releases need no such tag since pbr advances the patch on its own between releases. Verified end-to-end with dry runs and a local (unpushed, deleted after) v4.5.0.0a1 test tag: `make -n release-tag` picks up 2.4.1 by default, and 4.5.0 once the pre-release tag is present. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
sibson
changed the title
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
Follow-up to #317 (merged before this branch's later commits were pushed).
pbr derives the package version from git tags — this makes git tags the only source of truth for it, removing a second hand-maintained copy that could drift:
make releasenow readsVERSIONfrompython setup.py --version(pbr's own git-tag-derived version), not from CHANGES.txt.VERSION='M.m.p'still works as an explicit override. CHANGES.txt's heading becomes a downstream record — rewritten with the real released version + date at release time — rather than an input.make bump-version VERSION='M.m.p'tagsvM.m.p.0a1, pbr's pre-release marker convention. pbr can only auto-advance the patch version on its own between releases; this is the explicit human step for a minor/major release. Every untagged build after it computes asM.m.p.0a<N>.dev<commits>until the realvM.m.ptag lands viamake release.Test plan
make -n release-tagwith no pre-release tag present: derivesVERSION=2.4.1from git tags (next patch), computesNEXT_VERSION=2.4.2make -n bump-version VERSION=4.5.0prints the expectedgit tag/git pushforv4.5.0.0a1v4.5.0.0a1test tag (deleted after):make -n release-tagcorrectly picks upVERSION=4.5.0v4.5.0dev(a plausible but wrong tag format) is silently ignored by pbr — the.0aNformat is required, verified via local test tag before landing on this design🤖 Generated with Claude Code