Comments (7)
That's unfortunate. Hopefully there's a setting in Coursier that allows ascii sorting to be used, so the version with the biggest commit distance is picked. But there's really nothing that can be done, as this is a limitation in SemVer: there's no way to define a post-version version number - it only allows for pre-release numbers.
from sbt-dynver.
That's really unfortunate, because it means that releases tagged with sbt-dynver can't be used by projects that use SBT 1.4. I guess I'll have to invent or find some versioning algorithm that would be consistent with semver.
Thanks all the same!
from sbt-dynver.
Yeah, it's unfortunate. The closest thing would be to bump the patch version. But then the build metadata doesn't make sense, because instead of 1.0.0+3-1234abcd+20140707-1030
you need 1.0.1+3.1234abcd.20140707.1030
or maybe 1.0.1-3.1234abcd+20140707.1030
using the pre-release segment, either of which is misleading. It's just not a convention that supports what this plugin seeks to do.
from sbt-dynver.
Yeah, there has to be an automatic bump of some kind. Still, I feel like this can be done, even if not in this project. I really like the workflow this plugin provides (where you only need to push a tag to get a proper release with a version change), and It'll be a shame to have to switch to something less convenient.
I'll try and come up with a scheme that would satisfy SemVer and various Maven-derived utilities. It definitely won't be nice, but I only need it for in-house development, so it'll do. 😄
from sbt-dynver.
I'd be interested to know what you come up with. We might be able to make it an opt-in option or even just document how to apply the change in the README.
from sbt-dynver.
It seems like the Coursier's Version
is not really a semver implementation, but rather something else entirely. Like Maven, it has special qualifiers (alpha
, rc
...), but those don't include milestone
/m
for some reason...
For now I seem to have stumbled upon a relatively stable, but rather ugly versioning scheme described below. It seems to work with Maven and Coursier, as well as with proper SemVer (checked via the semverfi library). This has some idiosynchrazies built in (the -M*
tag suffix).
Tags
Tags have shape of v\d+(\.\d+){0.2}(-M\d+)?
. So v1
, v0.1
, v1-M1
and v1.2.3-M45
are all valid tags.
The dot-separated groups of numbers in the beginning are the base version. the -M*
suffix is for milestone releases. It is implied that v1-M1 < v1
.
Version numbers
These contain the following components. The base version component is separated from the other components via a dash (-
), and all the other components are separated via a dot (.
). Everything except the base version is optional.
- Base version, padded to three groups. If the last tag was not a milestone, and if we're not building a tagged release (as in, the tree is dirty or we had commits since the tag), the patch version is incremented. So when buliding
v1
we have1.0.0
here, when building dirty tagv1
we have1.0.1
, when building dirty tagv1-M2
we have1.0.0
. - (If the latest tag was NOT a milestone)
alpha
. - (If the latest tag was a milestone)
beta
. (Notmilestone
- Coursier doesn't support that). - (If the latest tag was a milestone) The number of the milestone,
incremented if the tree is dirty or we had commits since the tag. So when building(UPD: the incrementing part was silly and wrong).v1-M2
we have2
here, when building dirtyv1-M2
we have3
. - (if dirty or had commits) The number of commits since the last tag. Zero if no commits were made.
- (if had commits) First 7 hex characters of the last commit's hash, as a decimal number (so that it is compared as one group by all version systems). This is a tiebreaker for the previous component.
- (if dirty) Date of the current timetamp as
YYYYMMDD
. - (if dirty) Time of the current timetamp as
HHMMSS
. - (if had commits) First 7 (or 8?) characters of the commit hash. This doesn't do anything for ordering, but it's nice to have this in the version number. This has to be in the end because it different version systems can see it as one or multiple groups.
Examples
// v0.1-M2
0.1.0-beta.2
// v0.1-M2 + dirty tree
0.1.0-beta.2.0.20210521.153300
// v0.1-M2 + 3 commits
0.1.0-beta.2.3.180146467.abcd123
// V0.1-M2 + 3 commits + dirty tree
0.1.0-beta.2.3.180146467.20210521.153300.abcd123
// v0.1
0.1.0
// v0.1 + dirty tree
0.1.1-alpha.0.20210521153300
// v0.1-M2 + 3 commits
0.1.1-alpha.3.180146467.abcd1234
// V0.1-M2 + 3 commits + dirty tree
0.1.1-alpha.3.180146467.20210521.153300.abcd123
// V0.1.1-M1
0.1.1-beta.1
UPD: this can be made more regular by adding an empty component for dirty tree without commits, where in the other case we would have the commit hash. So, compared to the above
// v0.1 + dirty tree
0.1.1-alpha.0.0.20210521.153300
UPD2: We can also add a zero component after alpha
to match the milestone version in beta
.
from sbt-dynver.
I'll try and build a proof-of-concept implementation (with some tweaks) later this weekend.
UPD: Here it is. This is slightly less convoluted than what I proposed above.
from sbt-dynver.
Related Issues (20)
- What is the best way to prepend a dependency version number in front of the version ? HOT 4
- Allow getting full Git commit hash HOT 1
- Better support for meaningful SemVer-compliant versions HOT 3
- Possible to use with sbt-native-packager?
- Move to sbt org? HOT 3
- Config to automatically increment to next major, minor or patch version HOT 7
- Can't override `isVersionStable`
- Breaks with SHA longer than 8
- Should this plugin only be enabled on CI environment? HOT 1
- Selects wrong version if multiple lightweight tags point to the same commit HOT 1
- Artefacts not available HOT 10
- Admin stuff HOT 2
- Release 5.0.0 HOT 2
- dynverAssertTagVersion throws NullPointerException
- Support peeking at remote history / tags? HOT 1
- Task for printing out dynver for arbitrary commit
- Add setting/ability to use basic snapshot versioning with the hash.
- -rcX Tag suffix ignored HOT 1
- make behaviour configurable so that `previousStableVersion` can ignore M0/RC0 versions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sbt-dynver.