You can clone with
HTTPS or Subversion.
In many places we're checking the numpy version by comparing strings. This will break when numpy gets to 1.10. Need to fix this all over the codebase for the next release.
oops... duplicate of #2999
Should probably use LooseVersion.
LooseVersion is brain-damaged:
In : LooseVersion('1.7.0-rc1') > LooseVersion('1.7.0')
Following PEP 386 by taking over part of https://bitbucket.org/tarek/distutilsversion/src as private utils in scipy.lib is the way to go I think.
maybe numpy and scipy should follow the standard for alpha to rc version numbers that LooseVersion understand.
IIRC from last time I looked. (I had problems in statsmodels with a scipy 0.12-xxx)
It doesn't understand any version scheme. From PEP 386:
This class makes any version string valid, and provides an algorithm
to sort them numerically then lexically.
StrictVersion makes an attempt, but chokes on version strings of dev versions.
This tripped me up again today. Fix in progress.
I saw you were fast and went to distutils2 :) there's also distlib:
which, in theory, is what evolved from distutils2.
Thanks for the link. I already figured out that NormalizedVersion also doesn't work (doesn't recognize dev version strings). So I went with writing one myself: https://github.com/rgommers/scipy/compare/version-compare
Really? I haven't tried the code myself, but in theory 'dev' is present in the possible prerelase tags:
Fair enough, apparently it has to be [.devN]. so .dev, .dev-f1234afa and .dev-Unknown won't work. Too bad.
@rgommers: Is your version code part of a pull request, or still work-in-progress? Is it too early for comments yet?
Still WIP, needs some refactoring and still has one bug. Ran out of time for now, time for Christmas.
Happy holidays by the way!
Merry Christmas to everyone
BUG: fix comparison of NumpyVersion's 1.9.0 and 1.10.0. Closes gh-2998.
Now it's ready for review, PR sent.