[Python-Dev] Re: Stability and change

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