[Python-Dev] Maintaining old releases

[M.-A. Lemburg]

On 2008-08-13 22:32, Martin v. Löwis wrote:
>> It's difficult to use such download numbers as hint for the number
>> of deployed installations. 2.4.5 was not released as binary, so
>> interested parties had to compile that version by themselves and
>> those installations don't show up in your statistics.
> 
> You mean, they installed it *without* downloading it? How did they
> do that?

What I was trying to say is that you only see a single source download,
which someone then takes, compiles and possibly redistributed or
integrates into a product. As a result a single download can
easily map to quite a few installations - and that's what we should
base our assumptions on.

>> I'm sure that if we had released binaries as well, the number would
>> have looked different, esp. if you only look at the Windows binaries.
> 
> See, that's exactly the problem. We don't have the resources to provide
> Windows binaries. So even if the release contained regular bug fixes,
> I *still* would not have released Windows binaries.

I was just suggesting that the number of downloads would have
been higher had you released Windows binaries as well. We see that
all the time with the eGenix products.

Anyway, that's just statistics :-)

>> That's a valid point, but does this really warrant backing out
>> changes that have already been applied ? Isn't it better to get
>> at least some bugs fixed rather than to not fix them at all ?
> 
> Yes. Otherwise, neither developers nor users have a clear guideline
> what to expect.

I disagree on that, but I'm fine with such a plan if it's documented
well in advance.

>> Perhaps we should just document the maintenance of Python releases
>> more clearly and also plan for a final bug fix release 3 years after
>> the initial branch release. That way developers and users can also
>> adjust their plans accordingly.
> 
> There was clear documentation. It said "2.4 is done, finished, closed,
> over with, not maintained anymore". We had been doing that for many
> releases in the past.

Right, but that documentation was only available after the release
manager decided to stop creating releases for that branch - ie.
around the time that final release was cut.

In order to plan for the end of lifetime of a software product,
you need this information well upfront - for both the developers
(so that they can get fixes in before the end-of-lifetime) and
users (who will then have to plan to upgrade their installations
and products relying on Python).

> Now, you and me, we both want to change the policy. I want to change
> to provide security releases for a period of five years, and I think
> this is feasible with the resources that we have. You just suggested
> to provide bug fix releases for three years, and I think that is
> not feasible.

Actually, I was suggesting to have bug fix releases for 3 years
and security fixes for another 2 years (ie. 5 years lifetime
in total).

> In addition, it still would mean that we should not have
> done a bug fix release in 2008 (as 2.4.5 was released in March 2008);
> instead, the last bug fix release should have been made in November
> 2007. Nobody (including yourself) stepped forward at that time and
> offered to roll a release. 2.4 was release on November 30, 2004.

I don't want this written in stone, but there should be a pre-defined
roadmap for the whole lifetime Python release branch - from start to
end.

Please note that a policy is really just that: a guideline for
everyone to follow. It doesn't restrict us in maintaining a
release for more than the originally intended 3/5 years phases
or creating a bug fix release after the initial 3 years.

However, it should be seen as guideline for the minimum amount
of time a release is being maintained - for everyone to see
early (ie. in the Python release PEP) and use as basis for
making decisions on which release to take as basis for a software
project.

Regards,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 13 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611