[Python-Dev] New functionality in micro releases (was:Documenting branch policy)

[Barry Warsaw]

On Mon, 2003-09-08 at 18:29, Raymond Hettinger wrote:

>   * updates to separately maintained packages (like "email")
>      so that between major releases, Python won't get terribly
>      far behind the stable releases of the package.

You have to take things on a case-by-case basis.  I actually agonized
quite a bit about the email package in 2.2, but after discussing things
with Guido and the mimelib community, there was general consensus that
not fixing/upgrading the package was worse than doing so.  But I doubt
we'll do the same thing for Python 2.3, because the package is more
stable now, has been integrated longer, and the planned changes are
probably more radical.

This does point out a problem with the batteries-included philosophy
though: it's hard to upgrade packages that come with Python.  Say we
release email 3.0 and you want to use it in Python 2.3, what do you do? 
You can't just do a distutils install, because site-packages is searched
after the standard library.  I think we need more flexibility in
installing distutils packages, so we can install in various locations
that override standard packages (e.g. user-centric, system-centric,
etc.).

In general though, it's a good thing to default to a policy where micro
releases are bug fixes only.  Given the reality of the resources
available, time between major releases, and the fact that Python
development is a wholly volunteer effort, some amount of ugliness is
bound to invade the process.  That's where the BDFL uses his judgement
to make a decision and we live with it.

Take the True/False thing.  OOH, it was a new feature added to a micro
release.  OTOH it was backward compatible, helped future compatibility,
and was easily coded around to avoid micro-version skew.  Taken as a
whole, and given when the decision was made, it was probably a good one
although it caused a little bit of pain.

-Barry