Browse files


  • Loading branch information...
1 parent 3778656 commit 6d370cbf8f51339cd5a402f236f39e1c77eda961 @StefanKarpinski StefanKarpinski committed Feb 25, 2013
Showing with 1 addition and 1 deletion.
  1. +1 −1 VERSION
@@ -1 +1 @@

7 comments on commit 6d370cb


vtjnash replied Feb 27, 2013

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)


timholy replied Feb 27, 2013

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.


ViralBShah replied Feb 27, 2013

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.


nolta replied Feb 27, 2013

There's another problem, which is that the current master version is greater than 0.2:

julia> VERSION

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.


nolta replied Feb 27, 2013

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.

Please sign in to comment.