[Python-Dev] Stability and Change
Andy Robinson
andy@reportlab.com
Thu, 11 Apr 2002 00:23:30 +0100
>
> Message: 14
> Date: Wed, 10 Apr 2002 10:48:12 -0700
> From: Neil Schemenauer <nas@python.ca>
> To: Guido van Rossum <guido@python.org>, python-dev@python.org
> Subject: Re: [Python-Dev] Stability and Change
>
> Skip Montanaro wrote:
> > From where I sit this seems untenable, simply because what
> you're proposing
> > is going to require having three or four release managers at
> the same time,
> > each managing bugfixes and (what was the term?) "minor features" for a
> > previous release. Ain't no way I'm going to backport a change to three
> > previous releases.
But that's not the point. Who asked you to backport new
features? If the consensus is that 2.1.3 is pretty stable
and it is labelled as such, work should be minimal. But it
won't happen often. And by definition we don't want the minor
features backported; unnecessary changes to the code base would
destabilize it.
It's absolutely reasonable to find those with an interest
in maintaining a stable track and get them to do some of the
work. I'm more attuned to helping with packaging and
distribution simply because I can't program in C.
I think the solution is somewhat outside the core Python
team's hands. Those of us who really care about stability
need to get together and forge the consensus that we can skip
some releases; those of you wanting to forge ahead just need
to accept that there are sound reasons for many people to
have an upgrade cycle longer than 6 months. Having said that,
we just designate the 18-month ones arbitrarily, so that
(for example) ReportLab and Zope and eGenix are fairly likely
to want the same Python on a customer box in a given quarter.
In summary I'd like a note from Guido on the download page
saying "we do releases every 6 months but if you prefer a longer
cycle, go for 2.1.3 for now, and I will designate a stable 2.4.X
release some time in 2003". It doesn't mean 2.2 or 2.3 is bad
in any way, but it gives us a decent planning horizon.
Maybe EuroPython is the time to pick this up.
- Andy Robinson