[Numpy-discussion] Please comment on SVN versioning convention

Andrew Straw strawman at astraw.com
Mon Jul 24 17:18:37 CDT 2006

Sasha wrote:

>On 7/24/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>>Andrew Straw has emphasized that the current strategy of appending the
>>SVN version number to development versions of the SVN tree makes it hard
>>to do version sorting.
>I am not sure what the problem is, but if the concern is that
>>>>'' > '0.9.9'
>I suggest fixing that by appending '.final' to the release version string:
The concern is that there are a bazillion ways of sorting version
numbers but the version numbers from numpy's current svn tree don't sort
with (m)any of them. Sorting strings in Python is one way, using
setuptools or debian's dpkg are other ways.

Remember, all this is only a concern for those working from SVN versions
-- the releases are stripped of these numbers, anyway.

I don't really care what we use, it's just that if we want to make life
easy for people working from SVN, these automated tools should have a
way of knowing that what we currently call numpy 1.1.2881 precedes numpy
1.1 (these are current examples from the SVN tree). Here are some
proposals for this version:

1.0.2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before 1.1
for most tools out there.
1.0.post2881 - This would sort after 1.0 (and 1.0b and 1.0c) and before
1.1 for most tools out there, but is perhaps more clear.
1.1.dev-r2881 - this wouldn't solve the problem for Debian, but it would
for setuptools, which has special treatment for ".dev-r" (see
http://peak.telecommunity.com/DevCenter/setuptools). This has the
advantage of being only a minimal change from the current scheme.
1.0+1.1.2881 - I also think this would sort OK with most tools, and is
also a fairly minimal change. My only concern is the '+' might cause
some filesystems or tools to freak out.

BTW, Fernando, all this is so that we can still have the svn revision
number in __version__, but so that it doesn't screw up sorting.


More information about the Numpy-discussion mailing list