Sort versions without build after versions with build

[eschnett]

Currently we have v"0.5.0-dev" < v"0.5.0-dev+1". This breaks (at least) Compat for Julia installs where no build information is available.

I propose to change how versions are compared: If no build information is available, assume it is the very latest build, instead of assuming it is the oldest build.

[yuyichao]

I think the ones without + are also real version numbers. We can maybe change the build script to use 0.5.0-dev+9999 when the version is not available though

[StefanKarpinski]

I believe that SemVer has changed since I originally implemented this and now build strings should not be included in the precedence of versions. But that makes this not a total order.

[wildart]

SemVer states that: "Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence."

@yuyichao's proposal seems reasonable.

[eschnett]

I notice that the default Travis build script contains a git fetch --unshallow instruction. Maybe we should decide wether Julia can be built (with working Compat) from a shallow repo, and

• if yes, remove these lines from Travis, so that problems are exposed
• if not, detect this case, and abort during the build

[tkelman]

The default Travis script for packages? The next line of that is Pkg.clone(pwd()) which won't work from a shallow clone. That's quite unrelated to version number sorting.

[martinholters]

Having just re-read SemVer, I wonder whether instead of 0.5.0-dev+1234, we should rather be using 0.5.0-dev.1234 - after all, the 1234 is not really build metadata, it's part of the pre-release version. As 0.5.0-dev < 0.5.0-dev.1234 < 0.5.0-dev.unknown, the latter could then be used if the build script cannot figure out the version to the same effect as the proposed +9999.

Is it worth switching to this scheme for the 0.6 development cycle?

[tkelman]

#17434 is a better approach and supersedes this