[Distutils] ANNOUNCE: Distutils 0.1.2 released

Fred L. Drake, Jr. fdrake@acm.org
Thu, 16 Dec 1999 11:03:51 -0500 (EST)

Guido van Rossum writes:
 > who won't touch anything with "beta" in its name.  I still hear from
 > people who haven't upgraded to 1.5.2.

  You mean not everyone works off the CVS version?  Sheesh, I thought
the version number was just legacy...  How can anyone live without
string methods?  ;)

 > I wonder if perhaps for those cases (where there's a demand for stable
 > releases) some other strategy could be used?  Such as labeling
 > releases "stable" after the fact?  Or what Linus seems to do with the
 > Linux kernel (even = stable, odd = development; or was it the other
 > way around?).

  You have the even/odd thing right.  The problem with it is that it
really requires just as much planning as the release strategy you're
already using, it's just that the labels are semantically loaded
without being "syntactically" distinct.  I don't see that it's an
especially good way of doing things in general, however well it's
worked for the Linux kernel community.  (Note that I'm not saying it's 
a bad way, just that the benefits are not very clear.)
  I think there are a few reasonable approaches to the stable/devel

  -  Use labels like "alpha", "beta", "release candidate", etc.,
     possibly shortened to "a", "b", "rc", or whatever, to indicate
     various levels of stability in development/test releases.  Use
     two- or three-part numeric designations for "stable" releases.
     This is exactly what you've been doing with Python itself, and is 
     what appears to be most common, at least in the Unix world.

  -  Use either a "build number" approach similar to that used by
     PythonWin, and then declare things "stable" by re-releasing with
     a new number and only README/documentation changes and declaring
     stability as part of the release announcement.  Multi-part
     version numbers may still be useful here, but maybe no more than
     two parts.  I'd expect the first part to grow a little faster, so 
     the distinction between "Python" and "Python 2" would probably
     have to be made in a different way ("Python++" ;).

  -  Use "build number" or multipart numeric versions, and declare
     stability after the fact.  I'm much less enamored of this, simply 
     because I'd like to see the stability indication as part of the
     release.  This is probably the worst possible case for people who 
     don't follow the language news much at all (a group which will
     probably grow the most as Python penetration increases).  So
     don't use this one.

  Essentially, I don't see any compelling reason to change the
approach to versioning; anything with a version number of less than
one should be considered preliminary (Rainer Menzner always included
"beta" as part of pre-1.0 release numbers, just to be completely clear 
about the status.)
  But I agree, more frequent releases of the distutils package would
be useful.  Part of that is a matter of disseminating bug fixes and
feature improvements, but part of it is also maintaining interest and
visibility for the project.  Having an alpha or beta isn't any good if 
no one is interested in it.


Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives