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

Barry Warsaw barry at python.org
Tue Sep 9 13:09:36 EDT 2003

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

More information about the Python-Dev mailing list