… and 0.10 follows 0.9
Some open source projects jump from 0.9 to 0.10. So does Trac, so did Pygments. So please, don’t compare versions with string comparison operators. pkg_resources can parse versions for you so that you can compare them:
>>> from pkg_resources import parse_version
>>> parse_version("0.10") > parse_version("0.9")
True
If you don’t have pkg_resources you have problems getting running one of those anyways, but alternatively you can still split at every dot and try to compare the numbers into integers and falling back to strings:
>>> def parse_version(version):
... def _trynumber(x):
... try:
... return int(x)
... except ValueError:
... return x
... return tuple(map(_trynumber, version.split('.')))
...
>>> parse_version("0.10") > parse_version("0.9")
True
However, how this error happened I have no idea. TracMercurial doesn’t do checks on its own but uses setuptools for it, and that knows how to compare versions.
I think it is a semantic error, and just a proof that developpers are afraid of going to 1.0! unless one had something like “n.n.n” “0.1″ and “0.10″ are the same!
Comment by Joe — Thursday, June 19th, 2008 @ 2:15 pmThat has nothing to do with fear about a 1.0 release. The reason why Pygments released a 0.10 version is that we want to have lexer guessing working in 1.0 and we had to push out another release because the number of features added from the former version were just too many.
And version numbers are not decimal numbers in the sense that they are number - comma - number. There are minor releases and patch levels and whatever, so you can’t compare them with regular string methods anyways.
Comment by Armin Ronacher — Thursday, June 19th, 2008 @ 5:44 pmHaving recently received, and quickly dismissed, complaints about using 0.10.0 as a version number myself I couldn’t agree with your point more. It isn’t like we are talking about a minority of apps here either. On my system Gnome base and extras, the linux kernel, lame, sox, curl, busybox, most GNU tools(I have gzip 1.3.20 and tar 1.20) and even closed source apps like Opera(current release 9.50) all have at least one version component with two digits in their current releases.
Comment by James Rowe — Saturday, June 21st, 2008 @ 9:42 amI totally don’t see why incrementing the minor version number from 0.9 has to result in 1.0 — it just might look uncommon to people not familiar with more release steps. It still is evolving software, and there definitely should be no limitation to less than ten minor releases until 1.0 has to be out. Not to mention projects with active development going on for many years without ever touching something like 0.5.
As noted in the referenced post, something obviously goes wrong — but it isn’t Pygments’ fault just because of it following usual open source practices. Version numbers are no decimal numbers, and everybody depending on them should be aware of that fact.
Comment by Jochen Kupperschmidt — Monday, June 23rd, 2008 @ 3:33 pm@Jochen: Agreed, it seems silly (and arbitrary) to say that a major release is forced when you run out of minor release numbers in base 10. However, given that we’re aware that client code can tend to forget this critical parsing detail, it seems like using a tuple for __version__ has several advantages.
@Armin: Thanks for the insight — I’d love some more. I wrote Problems with Python __version__ parsing after reading your post, and I’m now subscribed to your feed :)
Comment by Chris Leary — Saturday, July 12th, 2008 @ 11:30 am