Permalink
Browse files

VERSION: 0.2

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

7 comments on commit 6d370cb

@vtjnash

This comment has been minimized.

Show comment Hide comment
@vtjnash

vtjnash Feb 27, 2013

Member

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)

Member

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

This comment has been minimized.

Show comment Hide comment
@timholy

timholy Feb 27, 2013

Member

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.

Member

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

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Feb 27, 2013

Member

We definitely want this to be 0.1+ or 0.2-pre or whatever is permissible with SemVer.

Member

ViralBShah replied Feb 27, 2013

We definitely want this to be 0.1+ or 0.2-pre or whatever is permissible with SemVer.

@StefanKarpinski

This comment has been minimized.

Show comment Hide comment
@StefanKarpinski

StefanKarpinski Feb 27, 2013

Member

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.

Member

StefanKarpinski replied Feb 27, 2013

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

This comment has been minimized.

Show comment Hide comment
@nolta

nolta Feb 27, 2013

Member

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

julia> VERSION
v"0.2.0+110975733.rd8b4"

julia> VERSION > VersionNumber(0,2)
true

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.

Member

nolta replied Feb 27, 2013

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

julia> VERSION
v"0.2.0+110975733.rd8b4"

julia> VERSION > VersionNumber(0,2)
true

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.

@StefanKarpinski

This comment has been minimized.

Show comment Hide comment
@StefanKarpinski

StefanKarpinski Feb 27, 2013

Member

The whole way these version numbers are generated needs a lot of work. Currently they're both ugly and not especially informative.

Member

StefanKarpinski replied Feb 27, 2013

The whole way these version numbers are generated needs a lot of work. Currently they're both ugly and not especially informative.

@nolta

This comment has been minimized.

Show comment Hide comment
@nolta

nolta Feb 27, 2013

Member

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.

Member

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.