Fix snapshot version naming and trim build hygiene#1772
Merged
Conversation
Previously the build appended "-SNAPSHOT" to git-describe output, so all
snapshots between releases were named after the *previous* release (e.g.
"4.3.0-3-gabcdef0-SNAPSHOT"), the opposite of Maven convention where SNAPSHOTs
are previews of the next release.
The fix: declare a `nextVersionBump` ("x" / "x.x" / "x.x.x") at the top of
build.gradle, and compute the next semver from the most recent release tag
plus that bump. Snapshots are then named "<nextVersion>-<shortHash>-SNAPSHOT"
(e.g. "5.0.0-23c681a8dc-SNAPSHOT"); including the hash makes each snapshot a
distinct, pinnable artifact.
Release builds (-Drelease=true) require HEAD to be on a semver tag and the
working tree to be clean; the tag is the version (nextVersionBump is ignored
on release — the tag is authoritative).
nextVersionBump is set to "x" since the next release will be a major one.
CI is on GitHub Actions (.github/workflows/tests.yml); Travis hasn't been used in years and Travis-CI.org no longer offers free OSS minutes anyway. The Ant build.xml has been superseded by the Gradle build for as long as anyone can remember. Nothing in the repo references either file. Also drops the matching /htsjdk.version.properties .gitignore entry, which was an artifact of the Ant build.
GitHub's actions/checkout defaults to a shallow clone (fetch-depth: 1) with no tags fetched, so palantir/git-version's `versionDetails().lastTag` returned an abbreviated commit hash instead of "4.3.0", which the new semver parser correctly rejected. Set fetch-depth: 0 on all three checkout steps.
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
nextVersionBump("x"/"x.x"/"x.x.x"for major / minor / patch). Snapshots are named<nextVersion>-<shortHash>-SNAPSHOT(e.g.5.0.0-abc1234-SNAPSHOT) — including a 7-char hash makes each snapshot a distinct, pinnable artifact.-Drelease=true) now require HEAD to be on a semver tag and the working tree to be clean; the tag is the published version.nextVersionBumpis informational on release — the tag is authoritative.nextVersionBumpis set to"x"since the next planned release is a major one (5.0.0)..travis.ymlandbuild.xml(Ant) — CI is on GitHub Actions and the Gradle build has been the source of truth for years. Drops the matching/htsjdk.version.properties.gitignoreentry.CONTRIBUTING.md"Version Numbering" and "Publishing a Release" sections rewritten to describe the new model.Why
Previously the build appended
-SNAPSHOTtogit describeoutput, so every snapshot between releases was named after the previous release (e.g.4.3.0-3-gabcdef0-SNAPSHOT) — the opposite of Maven convention, where SNAPSHOTs are previews of the next version. This made it impossible to publish, say, a5.0.0-SNAPSHOTahead of cutting 5.0.0.Test plan
./gradlew -q printVersionfrom a non-tagged commit prints<nextVersion>-<7charHash>-SNAPSHOTnextVersionBumpset to"x"/"x.x"/"x.x.x"produces 5.0.0 / 4.4.0 / 4.3.1 from currentdevtip (lastTag=4.3.0)-Drelease=trueon a non-tagged commit fails with "HEAD is not on a tagged commit"-Drelease=trueon a tagged commit with a dirty working tree fails with "working tree has uncommitted changes"-Drelease=trueon a tagged, clean commit prints just the tag (e.g.5.0.0)