[Python-Dev] PEPS, version control, release intervals

[Skip Montanaro]

One thing that I think probably perturbs people is that there is no dot
release of Python that is explicitly just a bug fix release.  I rather like
the odd-even versioning that the Linux kernel community uses where odd minor
version numbers are development versions and even minor versions are stable
versions.  That way, if you're using the 2.2.15 kernel and 2.2.16 comes out
you know it only contains bug fixes.  On the other hand, when 2.3.1 is
released, you know it's a development release.  I'm not up on Linux kernel
release timeframes, but the development kernels are publically available for
quite awhile and receive a good deal of knocking around before being
"pronounced" by the Linux BDFL and turned into a stable release.  I don't
see that currently happening in the Python community.

I realize this would complicate maintenance of the Python CVS tree, but I
think it may be necessary to give people a longer term sense of stability.
Python 1.5.2 was released 4/13/99 and Python 2.0 on 10/16/00 (about 18
months between releases?).  2.1a1 came out 1/18/01 followed by 2.1a2 on
2/1/01 (all dates are from a cvs log of the toplevel README file).  The 2.0
release did make some significant changes which have caused people some
heartburn.  To release 2.1 on 4/1/01 as PEP 226 suggests it will be with
more language changes that could cause problems for existing code (weak refs
and nested scopes get mentioned all the time) seems a bit fast, especially
since the status of two relevant PEPs are "incomplete" and "draft",
respectively.

The relatively fast cycle time between creation of a PEP and incorporation
of the feature into the language, plus the fact that the PEP concept is
still relatively new to the Python community (are significant PEP changes
announced to the newsgroups?), may be a strong contributing factor to the
relatively small amount of feedback they receive and the relatively vocal
response the corresponding language changes receive.

Skip