[Distutils] Version numbers for module distributions

[Greg Ward]

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