Wow, looks like I found the hot-button issue that this SIG was looking for. Fun! Quoth Greg Stein, on 10 December 1998:
It is bogus to have distutils try to proscribe rules of semantics to the version numbering. ^^^^^^^^^
I think you meant "prescribe" not "proscribe". Whatever! Anyways, everyone who's howling in protest against forcing certain semantics down module developers' throats missed an important point: those were only *guidelines*, and what's more they were only *proposed* guidelines! (OK, OK, only Greg Stein howled. Andrew and Marc-Andre stated their case nicely.) Heck, you could even interpret the fact that "0.5a1" or "1.5.2a1" are "illogical" version numbers as flaws in my proposal, and come up with different guidelines that don't have that problem. Feel free! One possible modification to the guidelines based on the feedback received so far: "changes in major version number imply a change in the interface, *except* for the 0.9.x to 1.0 change." It would be good to stress that you really shouldn't break the interface in a "mature" (>= 1.0) product without bumping the major version number. The fact remains, though, that under my proposed version numbering system (which mandates syntax and suggests semantics), developers would be free to use version numbers however they like. The proposed semantics are *suggested guidelines*. How on earth could such things be enforced, anyways? (OK, here's an idea: if you upload version 1.3.2 to an archive, the archive software unpacks 1.3.2 next to 1.3.1, and makes sure that you haven't added any new methods or functions, or any parameters to existing methods or functions. JUST KIDDING!) My rationale for having some *suggested guidelines* is that most developers spend several years groping in the dark trying to figure out how to assign version numbers to their software. Experienced hackers eventually figure it out, and really smart, far-thinking hackers just "get it" immediately and come up with a system that will work for them henceforth and forevermore. I think most people, though, would benefit from a little friendly advice informed by the many decades of collective experience that will inform the "How to Develop and Distribute Python Modules" document that will come of all this. Greg also had a suggestion about loosening up the syntax, essentially by reducing it to a set of comparison rules:
1) a version number has 1 or more numbers separate by a period or by sequences of letters. If only periods, then these are compared left-to-right to determine an ordering. 2) sequences of letters are part of the tuple for comparison and are compared lexicographically 3) recognize the numeric components may have leading zeroes
As long as we can a) explain the syntax, and b) write code to parse and compare version numbers, then any proposal is valid. This one sounds valid. However, keep in mind that we're dealing with a much smaller and more cohesive population of existing packages than the guys at Red Hat deal with. It might turn out that a heck of a lot of existing Python module developers think there should be a standard (and fairly rigid) *syntax* for version numbers, and are willing to change their habits to go along with this. If not, we can adopt Greg's much looser syntax proposal, and if there's anybody left over who can't or won't fit their version numbers into that syntax... well, too bad. Greg (the other one) -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913