Singularity: WISH: singularity --version to distinguish between release and devel versions

[HenrikBengtsson]

Currently one gets:

$ singularity --version
2.2

regardless of whether the install is based on the 2.2 release or the Git master branch.

I'd like to suggest that the version should clearly indicate that one has a developer installation such that one can trust that 2.2 is truly the 2.2 release version. This should also help when users report issues / bugs - users that may not be the ones who installed Singularity.

One approach, which is successfully used by the R community, is to add suffix -9000 (or .9000) to the version for anything under development, e.g.

$ singularity --version
2.2-9000

This supports comparisons, i.e. 2.2 < 2.2-9000 < 2.3 and clarifies to the user that the version is something out of the normal. The 9000 suffix doesn't have to be incremented.

[gmkurtzer]

Apologies for ongoing Git ignorance, but ... Do you know how to get a branch and commit count from Git? We can certainly add something like that to the autogen.sh.

[jmstover]

@gmkurtzer What about using something like:

git log | head -n 1 | cut -f 2 -d ' ' | cut -c 1-8

i.e. Take first 8 chars of the commit from the log. Then build the version out like:

$major.$minor(.$extra)-$rev

-J

[HenrikBengtsson]

@gmkurtzer, are you looking for a way to do automatically increment the version? One of the critiques that hard-core Subversion folks has against Git is that you often don't have a linear Git history and it makes it hard do to things like this. Would appending the 7-len commit hashcode to the version be an alternative? That wouldn't support comparisons though, but it could also be returned as part of "additional" version information, e.g.

$ subversion --version
2.2.0-9000 (commit 3a2155e)

BTW, I noticed that in the releases you drop z from x.y.z when z == 0. For my suggestion to add -9000 to work, that would would require that the develop version to always include z (as in the above example).

[gmkurtzer]

This will show the number of commits since the version's tag:

git rev-list 2.2.. --count

Or we can just implement the total number of commits:

git rev-list --all  --count

[HenrikBengtsson]

Interesting; didn't know about this.

I'm not sure, but I don't think you want to use --all at all, because that is the total number of commits including all branches. This would cause the version counter to go up in on branch even if nothing changes to that branch. I think this is what you're after:

$ git rev-list --count master
2040

which is the number of commits at the head of master since the beginning of the repos, resulting in version string 2.2.0-2040.

It can be made relative to a tag / commit by manually calculating the difference to:

$ git rev-list --count 2.2
1548

resulting in version string 2.2.0-492 (from 2040-1548=492).

Using a counter relative to most recent release seems more natural and give a sense of how much have changed in that branch and avoids having to manually trying to compare really large numbers later on.

I hope your idea of using git rev-list --count is correct, because it looks pretty neat.

[HenrikBengtsson]

I just built master and noticed:

singularity --version
2.2.99

Since 2.2.1 is out, I suspect this should be 2.2.1.99 such that 2.2.2 > 2.2.1.99 when / if 2.2.2 comes out.

Is the version string defined solely in configure.ac:

AC_INIT([singularity],[2.2.99],[[email protected]])

or are there are files that needs to be updated as well?

[vsoch]

I'm not sure exactly what we would want, but I don't think we want three decimals / 4 groups of numbers, haha. Maybe something along these lines?. I also think it's generally understood that we messed up this current Github flow (and the corresponding versions too), and we can fix this more correctly with the start of 2.3.

I think the choice for 2.2.99 is because the next release is going to be 2.3... does that not make sense?

[vsoch]

if at all possible, I'd like to replace our complete lack of awareness for how to do this correctly with "version numbers... living on the wild side!" #singularity lol

[gmkurtzer]

Hi @HenrikBengtsson,

The GitHub repo is in a bad state right now because what is in the 'master' branch actually is a dead end. Honestly, I would like to revert the master branch to what is in the 2.x branch, as that would be much more accurate of a typical gitflow, but that would end up reverting some features that people are currently using from the master branch. The versioning oddities are an effect of the broken state of the repo, and everything will be fixed as soon as we prepare for the 2.3 release.

@vsoch OMG... Ahhhhhhh, nooooo... NOT THAT!!!!

[vsoch]

:tiger:

[HenrikBengtsson]

Sounds good.

I'm in favor of public stable releases having a x.y.z version format and any on-going development code has another level of version number appended to that to make it very clear code can be broken at any time.

I do find the annotation of x.y.z that Semantic Versioning attempts to do is helpful, especially since I've before that basically ended up with my own home-cooked flavor-of-the-month version scheme that was hard for others to second guess. (At least now I know that I need to bump x when there are significant API changes and whenever there are pure bug fixes I bump z. I'm occasionally shooting from the hip when it comes to bumping 'y'.)

[GodloveD]

Hey I think we have done this right? If not feel free to re-open. 😺

[HenrikBengtsson]

In case someone else wonders, below is what singularity --version might give depending on how it / what was build/installed. The examples are based on INSTALL.md.

If you build from Git, make sure to do make clean first in order to clean out any memory of previous version tags. If not, singularity --version will give an invalid output. (Q: Couldn't/shouldn't the version tag dep be taken care of by make?)

Built from release tarball 2.4

$ v=2.4.0
$ wget "https://github.com/singularityware/singularity/releases/download/${v}/singularity-${v}.tar.gz"
$ tar -xvzf singularity-${v}.tar.gz; cd singularity-${v}
$ ./configure --prefix=/usr/local; $ make; $ sudo make install

$ singularity --version
2.4-dist

Built from Git tag 2.4

$ git checkout tags/2.4 -b 2.4
$ git log | head -1
commit 81bf030a28aa1afe517ea1a83145d6fefe9a1a59

$ make clean ## to reset version tag
$ ./autogen.sh; ./configure --prefix=/usr/local; make; sudo make install

$ singularity --version
2.4-heads/2.4.g81bf030

Built from Git tag 2.3.1

$ git checkout tags/2.3.1 -b 2.3.1
$ git log | head -1
commit e214d4ebf0a1274b1c63b095fd55ae61c7e92947

$ make clean ## to reset version tag
$ ./autogen.sh; ./configure --prefix=/usr/local; make; sudo make install

$ singularity --version
2.3.1-heads/2.3.1.ge214d4e

Built from Git master HEAD

$ git checkout master
$ git log | head -1
commit 67293a93bea931f7cfd3d82292116f38a8022e7e

$ make clean ## to reset version tag
$ ./autogen.sh; ./configure --prefix=/usr/local; make; sudo make install

$ singularity --version
2.4-master.g67293a9