-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
potentially customize sbt-git versioning #122
Comments
Been doing some research on the semver+git describe options. A live "defacto standard" I found in the NodeJS/NPM community is basically
I actually kinda like this upon reflection, as you completely make your local state into the build metadata field only, and releasing a pre-release version becomes always an active decision, e.g. tagging If melding that mechanism with "SNAPSHOT" (it's still unclear to me if we want this for local versioning), I imagine we would simply append it as the buildinfo suffix in all cases where we are not on a direct tagged commit, e.g. (I'm assuming this would be compatible with SBT versioning schematics, however if not, a close reading of the semver spec does seem to technically allow a |
(Documenting some of my conversations with @outkaj for broader discussion and async. Note this is a discussion related to the upcoming changes switching to sbt-git versioning, not what is currently in master.)
Currently we have
sbt-git
utilizing it's default versioning schematic, which is almost identical to whatgit describe
does.In this schematic, if the last release was tagged
v1.2.3
, you may notice your local version is something like1.2.3-7-a1b2c3d
. This means you are7
commits past release1.2.3
, and the latest commit was SHAa1b2c3d
.There are two changes we may want to discuss making to this behavior.
Making the versions more SemVer compliant
There is an official specification for allowing pre-release versions in SemVer, and this differs from it a little. Basically it's this:
(For more formal spec with more detail see https://semver.org)
Version ordering: The most notable change is the that in SemVer,
1.2.3-7
would indicate a prerelease of1.2.3
, e.g. something that comes before it.This is very common with pre-releases in SemVer, and is widely adopted in the wild. (This is what we do with NPM in openlaw-client, as it's the default.)
Metadata: In SemVer, the separator before build metadata field should be
+
. I don't see this as often in the wild, but it's in the specification. I consider this to be less of an issue but it's there.Combing the above, the simplest set of changes would mean
1.2.3-7-a1b2c3d
would become1.2.4-7+a1b2c3d
.Neither would affect public releases at all unless we wanted to start pushing these versions to GitHubReleases+BinTray. This is more for our local development currently? Unknown to me is how SBT considers version ordering and how this might affect it.
We could also use a different schematic for pre-release versions if we ever want to actually "release" them, and not care so much about what sbt-git shows locally when doing development. Combining this choice with the SNAPSHOT option below could help enforce that better.
Adding in
SNAPSHOT
for more casesCurrently
sbt-git
only appendsSNAPSHOT
if your local worktree is dirty (e.g. non-commited changes). We may wish to make it so anything not explicitly on a release tag is considered aSNAPSHOT
-- and thus can't accidentally be released to BinTray.(If we did that, but still wanted to release a "pre-release" version at some point, we could just do a semver prerelease git tag within our normal release process and it would work.)
Implementation
sbt-git gives us the flexibility to totally override the versioning schematic as we see fit. So anything we want should be achieveable. An example from someone's blog post where they were doing something fairly similar (I think? I still don't grok sbt-git configuration intuitively. But it still shows it's easy to get under the hood):
The text was updated successfully, but these errors were encountered: