[Python-Dev] Stability and Change (original) (raw)

Skip Montanaro skip@pobox.com
Tue, 9 Apr 2002 23:15:12 -0500 

>> Frequent releases cost me money.  
...
>> I desperately want to see a "recommended stable version" declared
>> with intervals of 18 months or greater.
...
>> 24 months would be even better.

Guido> I've heard "18 months or more" from several (presumably)
Guido> independent sources now.  I'd like to give you that, but for me,
Guido> as a developer, it feels like an eternity, and I'm more
Guido> comfortable with 6-8 months for major releases (of the 2.2 kind).

Guido> How about this as a compromise: each major release (which for
Guido> Python is 2.0, 2.1, 2.2, 2.3 etc., never mind that only the
Guido> "minor" digit varies -- that's how we number 'em) has a
Guido> shelf-life of at least three subsequent major releases or 24
Guido> months, whichever is shorter, but never less than 18 months.
Guido> Shelf-life means that we follow up with bugfix releases (like
Guido> 2.1.1, 2.1.2, 2.1.3) to maintain and improve stability, if
Guido> necessary back-porting selected minor features, but with the
Guido> absolute guarantee that (a) the binary API doesn't change, so C
Guido> extensions are completely portable between bugfix releases, and
Guido> (b) no old code break unless it depends on bugs being present or
Guido> names being absent from any given namespace. 

...

Guido> Comments?

Guido,

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. I can barely manage getting the occasional patch or bugfix mostly correct on the trunk, and I suspect that other peoples' accuracy will diminish as they have to backport patches (possibly with subtle code rearrangement) to multiple previous releases. By proposing this, all you're doing is making more work for the people on the SF developers' list.

While I'm sure this probably won't sit well with Andy and other commercial folks listening, I'm going to suggest that it's wrong for ReportLabs to expect the Python community as a whole to support their desire to run old versions of Python. I don't get a penny from the work I put into the Python source tree. Meager though my effort may be, it is still contributed time. Andy at least has the prospect of billing a client to cover (some of) his time. While that may cut his profit margins, I don't think it's unreasonable to expect ReportLabs and other companies that want to continue to run old releases to pay for that privilege one way or another. They can step up to the bar a couple different ways, either taking on some of the labor themselves or contracting it out (possibly by supporting someone in the community who would function as a release manager for Python version(s) of interest).

where-can-i-send-the-invoice?-ly, y'rs,

Skip