[SciPy-dev] Next SciPy release

[Andrew Straw]

On Jul 21, 2006, at 1:03 AM, Ed Schofield wrote:

>
> Hi all,
>
> I'd like to make a new SciPy release early next week to sync with
> NumPy 1.0b1.

Great!

> It would have been nice to release SciPy 0.5.0 to
> coincide with NumPy 1.0 (final), but I suppose the next release
> should be numbered 0.5.0, following Andrew Straw's suggestion in
> http://projects.scipy.org/scipy/numpy/ticket/170.

After re-reading that sentence a few times, it's still not clear to  
me exactly what you mean. Let me skip to my suggestion, which  
actually seems to be what you're rejecting:

numpy    scipy
0.9.8    0.4.9     # release (already done)
0.9.9.x  0.5.0.x   # svn revision x (already done)
1.0b1    0.5.0b1   # release
1.0b1.x  0.5.0b1.x # svn revision x
1.0b2    0.5.0b2   # release
1.0b2.x  0.5.0b2.x # svn revision x
1.0      0.5.0
1.0.x    0.5.0.x
...

Technically, yes, this violates the principle that the temporal  
sequence of version numbers should also sort with setuptools or  
debian's dpkg or whatever. (scipy numbered 0.5.0.x after the 0.4.9  
svn versions but that temporally precedes the 0.5.0b series would  
sort after the 0.5.0b series). However, I'd rather deal with that  
than break the 2:1 ratio that has happened with the release version  
numbers, which would be particularly nice to have at 1.0/0.5. If we  
stick to the above suggestion, future releases (and interim svn  
versions) should sort to the temporal order.

As a digression (since discussing version numbering schemes is so  
productive), numpy is presumably going to have a slowed release cycle  
after 1.0, and thus we probably won't be able to keep scipy in such  
version-number lock(half)step. (Other ways to keep the lockstep exist  
but seem less desirable IMO: few scipy releases will get made, numpy  
version numbers will have to jump to allow scipy some room to grow.)

Back to the first issue -- one could argue that we might as well  
break the lockstep between numpy/scipy version numbers now, as I  
think you might be. My opinion leans towards opposition because the  
releases are so close to some nice, round easy-to-remember numbers.

Anyway, debian's dpkg has ways to force version numbers to sort  
properly, even if the release numbers don't. I don't know if  
setuptools does, but I presume you can at least force things to work  
somehow.

Finally, this is really only an issue for people packaging stuff out  
of svn, who basically know they are living on the bleeding edge to  
begin with, and I hope no one spends as much time on this issue as I  
have! :)

-- Andrew

PS I'm posting this email back into Trac so it doesn't get forgotten  
when we get closer to future releases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20060721/d660d157/attachment.html>