[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