Use proper Semantic Versioning for dev versions

[martinholters]

According to Semantic Versioning 2.0.0, the part after a + in a version number is build metadata that "SHOULD be ignored when determining version precedence". But of course, if we want to compare "0.5.0-dev+1234" and "0.5.0-dev+2222", we definitely want to consider the part after the +. The problem here is that this dev version counter is not build metadata, it is part of the pre-release version information which should be between the - and the +. So I propose to switch the versioning scheme to "0.6.0-dev.1234", starting with the 0.6 development cycle. Admittedly, I have no clue how much trouble this change would mean.

[lobingera]

Maybe you can re-phrase the headline to 'Use Semantic Versioning for dev versions'...

[simonster]

I think Julia's versioning scheme is based on SemVer v2.0.0-rc.1 which included build metadata in precedence calculation. Not sure if "upgrading" SemVer is worth the trouble at this time.

[tkelman]

We'd have to make sure the build number is incremented monotonically over such a change, since

julia> v"0.6.0-dev.1234" > v"0.6.0-dev+1233"
true

julia> v"0.6.0-dev.1233" > v"0.6.0-dev+1234"
true

[martinholters]

@simonster

I think Julia's versioning scheme is based on SemVer v2.0.0-rc.1 which included build metadata in precedence calculation.

And I'd also say we should keep it this way for how version strings are handled because having a total ordering seems really useful. But that point aside, I still think the commit counter (or whatever it should be called) is not build metadata, but rather belongs to the prerelease version.

Not sure if "upgrading" SemVer is worth the trouble at this time.

How much trouble would it be, then? I guess there are only few places in Julia where the version string is constructed, and then there is the version.sh script in Compat. Shouldn't adjusting these be sufficient?

@tkelman

We'd have to make sure the build number is incremented monotonically over such a change

I'd say the build number (we're talking about the part currently following the +, right?) should increase monotonically within one release cycle no matter how we construct the final version number. That said, at the moment of the proposed change we could actually make it jump back (but of course shouldn't) and still get correct ordering, as your examples show. Or did I miss your point here?

Of course, undoing this change would be a different story...