I noticed the linux kernel uses e.g. 0.1+ to indicate something after v0.1, but before the official release of v0.2. for the sanity of any binaries released in this period of time, do we want to adopt a similar strategy? (e.g. there's a windows binary from pre-v0.1-official that is tagged v0.1 in the sysimg because of when the version tag was updated)
Just tuning in here now, this will definitely help. Whatever ends up being decided re the numbering scheme, it's nice to have a difference.
We definitely want this to be 0.1+ or 0.2-pre or whatever is permissible with SemVer.
I've already added support for version numbers like v"0.1-" which is not an officially valid SemVer version, but is ordered to be before all other v"0.1" version numbers. We could have v"0.1+" similarly be a non-official version number that is greater than all other version numbers starting with v"0.1.0". It's an easy enough change to make.
However,I'm not entirely sure it's necessary. We could just have VERSION contain whatever the next version the code base is leading to is. Thus, VERSION = 0.1.1 in the release-0.1 branch, but VERSION = 0.1 in master.
There's another problem, which is that the current master version is greater than 0.2:
julia> VERSION > VersionNumber(0,2)
Fixed by 87b2a8a, which tries to figure out if a commit is a prerelease version. But we could also just put 0.2-dev in the VERSION file, so the patch might be overkill.
The whole way these version numbers are generated needs a lot of work. Currently they're both ugly and not especially informative.
Yeah, sorry about the version numbers -- i should never have used ctimes. The patch also switches to using git describe, so hopefully they're a bit less sucky now.