Building with NO_GIT=1 causes problems with Compat.jl and other packages

[jakebolewski]

Building with make NO_GIT=1 causes VERSION to not contain the build number. This breaks a lot of packages that check the specific build number for compatibility.

[sjkelly]

The Julia in Debian doesn't contain the build number either:

steve:~$ /usr/bin/julia -e '@show VERSION'
VERSION => v"0.3.2"

[pao]

I believe that's expected for distribution builds made off a tag, @sjkelly; what @jakebolewski is experiencing seems to be the incremental numbering of the development versions, which are used as breakpoints for switching between implementations in Compat.jl.

[tkelman]

Said this in person yesterday, but yeah this is bad... should a NO_GIT build of a dev version just default to something ridiculous like 0.4.0-dev+999999 ? That's at least wrong in the assuming that everything is as up-to-date as possible direction...

[nalimilan]

When should NO_GIT builds be used? It would make sense to require people to only build Julia either from the git tree, or from a tarball generated via make [full-]source-dist (saving the build number in a file). Assuming a dummy build number will only create more subtle issues that will be hard to debug: better print an error in that case.

[tkelman]

From a release tag it should be fine to build with NO_GIT now that submodules are gone. Otherwise on master it does cause issues and should maybe be warned against more strongly? If you manually run the command to generate version_git.jl then it also works properly.

[stevengj]

julia> v"0.4" >= v"0.4-dev+1000"
true

julia> v"0.4-pre" >= v"0.4-dev+1000"
true

julia> v"0.4-dev" >= v"0.4-dev+1000"
false

julia> v"0.4-dev+" >= v"0.4-dev+1000"
true

So maybe the NO_GIT dev build could use v"0.4-dev+"?

[stevengj]

Actually, why not just change isless to make v"0.4-dev" > v"0.4-dev+1000" return true? i.e. assume that v"0.4-dev" is master?

@StefanKarpinski, is there a good reason why v"0.4-dev" > v"0.4-dev+1000" is currently false?

[StefanKarpinski]

I seem to recall that when I implemented versions, the semver spec included build info in "precedence" (i.e. version ordering), but now it explicitly doesn't:

Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence)

It seems kind of crappy to me to make version numbers non-totally ordered, so I'm curious why they did that. It would let us change this ordering without being any less in compliance with the version spec – but also not fully in compliance, since the spec seems to indicate that we should ignore build info when it comes to version ordering.

However, I think using the version 0.4.0-dev+ is the right thing to do. My reasoning is that we are using this name to mean a continually changing series of commits, which is not how version numbers are supposed to work at all, but is ok for a pseudo-version-number like 0.4.0-dev+ which is intentionally not a valid name for an actual version.

[simonster]

From the examples it sounds like semver wants 0.4.0-dev.n instead of 0.4.0-dev+n. But semver also says:

Build metadata SHOULD be ignored when determining version precedence.

The choice of SHOULD vs. MUST suggests it's not too bad if we do use it.

[StefanKarpinski]

Just to prove to myself that I'm not imagining things, in semver v2.0.0-rc.1, the precedence section read:

Precedence MUST be calculated by separating the version into major, minor, patch, pre-release, and build identifiers in that order.

I'm pretty sure that was the version of semver I based the implementation on.

[jakebolewski]

Looks like it got dropped in v2.0. The language changed a lot between the final and RC versions.

[jakebolewski]

I think we should go with @stevengj 's suggestion here and close this issue.

[stevengj]

If you read the spec, it defines SHOULD as a recommendation which we are free to ignore without violating the spec.