[Numpy-discussion] Version numbers again

[Andrew Straw]

Travis Oliphant wrote:
> I'm still looking for ideas on version numbering.
>
> Right now, the trunk is at version 0.9.9  but this has bug-fixes from 
> the 1.0b1 release.  The next release will be 1.0b2 and should occur in 
> about a week. 
>
> I don't really like having the trunk use a 'lower' version number than 
> the releases but I'm not sure what to do.  The problem seems to stem 
> from wanting to have the version number sort somewhat reasonably when 
> the development number is tacked on.
>   
Sasha is correct that most users of these version numbers can override
the version numbers that come direct from numpy. The one system that I
suggest we really try to work with out-of-the-box, however, is
setuptools, which, luckily, attached special meaning to ".dev" in a
release number, so that it sorts _before_ the release. (In setuptools
jargon, ".dev" is a pre-release tag. See
http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
for more info.) In other words, with setuptools, 1.0b2.dev-r2891 sorts
after 1.0b1 and pre 1.0b2. If nothing else, this maintains greatest
consistency with what the current system, merely adding the ".dev-r"
prefix before the svn revision.

I suggest a special attempt to work with setuptools out of the box
because it's partner-in-crime, easy-install, is able to automatically
find, download and build from releases or svn development versions, and
it would be great to let our users use this standard machinery if they
like. And we'll get calls for help if it doesn't. We can expect
packagers from Debian and elsewhere to do the right thing, however, so
we shouldn't worry overly about them.

Here is a clipping from a recent session with setuptools'
pkg_resources.parse_version() function, which returns sortable tuple:

In [15]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.dev-r2891') < 
pkg_resources.parse_version('1.0b2')
Out[15]: True

In [16]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2dev-r2891') < 
pkg_resources.parse_version('1.0b2')
Out[16]: True

In [17]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.2891') < 
pkg_resources.parse_version('1.0b2')
Out[17]: False

In [18]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2.dev2891') < 
pkg_resources.parse_version('1.0b2')
Out[18]: True

In [19]: pkg_resources.parse_version('1.0b1') <
pkg_resources.parse_version('1.0b2-dev2891') < 
pkg_resources.parse_version('1.0b2')
Out[19]: True

So, basically, setuptools could handle any of these cases except what
we've currently got. Admittedly, these schemes depend on setuptools'
special handling of "dev" as a pre-release tag, but at least it's very
nearly consistent with our current situation.

On the other hand, we could try and work even with systems that don't
have special pre-release tags. I think the system you propose below
would work for this with one caveat.

> Will it work to have the trunk reflect the version number that was most 
> recently released?  In other words we could have the trunk be 
> 1.0b1.<svn_version>
>
> So, a version number change doesn't happen until *after* the *next* 
> release.  Once 1.0b2 is tagged then the version number on the trunk 
> changes to 1.0b2?
>
> When 1.0 comes out, then the trunk will be
>
> 1.0.<svn_version>
>
> A branch will then also be made with version number
>
> 1.0.0.<svn_version>
>
> when a 1.0.1 release is made the branch version number becomes
>
> 1.0.1.<svn_version>
>
>   
The caveat is that sorting across branches, as you point out, is
difficult. (Although I must say that this seems like a difficult thing
to get "right", considering that the whole point of branches is to have
two versions simultantously current.)

But, in your proposal above, most (or all) sane version sorting systems
would at least sort both numpy releases and numpy svn versions into
their actual order. Which is all I was asking for, but maybe the cost
for breaking with out versioning tradition is too much, as some people
suggest.
> I don't think this solves all the version numbering issues someone is 
> going to have if they use SVN-builds as a distribution, but perhaps it 
> might give some sense of order to the system.
Thanks for taking this issue seriously. On the one hand, it's ridiculous
to spend our times worrying about version numbers, but on the other
hand, we should be able to interact with automated tools whose purpose
is to make life easier (in the long term, anyway!).

Cheers,
Andrew