Require all three parts of the version in a tag - #565
Merged
Conversation
parseVersion padded a missing part with a zero, so 'v4.7' and 'v4.7.0' were the
same build under two names - version name 4.7.0, code 40700, either way. That
padding is why the tags are in two formats: nothing ever had to choose, and the
choice drifted at v4.8.0.
Three parts are required now, and a two-part version fails the release build
rather than being quietly completed. A convention could not have done this; the
tag is the only place the version exists, so the build is the only thing that
can refuse a badly spelled one.
The tags already pushed are left as they are, in both formats. A release asset
is served from a URL carrying its tag name and F-Droid rebuilds old versions
from those names, so renaming them would break both to buy nothing: the version
code has never depended on the spelling.
Cleaned up alongside this, outside the tree: nine bare duplicates ('3.2.5' next
to 'v3.2.5') that existed only in a local clone, the 'v.2.12.0' typo tag, and
the twelve tags between v1.1.7 and v2.11.5 that had no github release. Tags and
releases are 55 each now, and match.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015yn6kzFspdCFEZFYZZxwY8
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.
parseVersionpadded a missing part with a zero, sov4.7andv4.7.0were the samebuild under two names - version name
4.7.0, code40700, either way. That padding iswhy the tags are in two formats: nothing ever had to choose, and the choice drifted at
v4.8.0.Three parts are required now, and a two-part version fails the release build rather than
being quietly completed. A convention could not have done this - the tag is the only
place the version exists, so the build is the only thing that can refuse a badly spelled
one.
-Podr.versionv4.8.0,4.8.0v4.7v4.100.0Verified by configuring the build with each of those.
The existing tags are left alone
In both formats, deliberately, and
README.mdsays why. A release asset is served from aURL carrying its tag name, and F-Droid rebuilds old versions from those names, so
renaming them would break both to buy nothing: the version code has never depended on the
spelling.
Cleaned up alongside this, outside the tree
3.2.5next tov3.2.5) that existed only in a local clone -github never had them
v.2.12.0typo tag, same commit asv2.12.0, no release attachedv1.1.7andv2.11.5that had noneTags and releases are 55 each now, local matches remote, and
v4.13.0keeps the latestbadge.
🤖 Generated with Claude Code