[Python-Dev] Re: Stability and change (original) (raw)

Skip Montanaro skip@pobox.com
Tue, 9 Apr 2002 09:41:57 -0500 

SM> It works for 2.4.x for x >= 3 and for 2.6.x for x <= 9.
...
SM> No support for any development branch releases (e.g. 2.N.x, where N
SM> is odd) is implied.

BAW> IMHO it will still confuse a lot of people.  I don't think it's the
BAW> same as the Linux kernel because I suspect that people upgrade
BAW> their kernels a /lot/ less often then they'll upgrade their Python
BAW> version.

What's the version numbering scheme got to do with the rate at which people upgrade their local copy of Python?

Here's my gut feeling on timing of releases. Typically, I would expect point (micro) releases on the experimental branch to occur about once a month, and probably be little more than adding a CVS tag and generating a source tarball. Hopefully, no release manager would be required. There should be few frantic checkins because if you miss this release, the next one's only a month or so away.

On the stable branch, releases would come less often, perhaps as often as once every two months, but more likely every four to six months, whenever "enough" bug fixes had been applied or when a particularly nasty bug got fixed we want people to take advantage. The generation of such releases would be a bit more involved, but not terribly much. If you get rid of micro release numbers in non-code files (like the docs), I think you can disconnect the timing of code and documentation a bit.

Splits of the experimental branch into new stable and experimental branches would probably occur about once every 12-18 months and be governed by the functional completeness of the experimental branch and rate of bug fixes applied to it. It might also be driven by new features you want to get in but down want to upset the apple cart so-to-speak. In that case I'd say you split, then apply the new features to the new experimental branch.

Skip