[Python-Dev] Stability and Change

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