[Python-Dev] Maintaining old releases

["Martin v. Löwis"]

> 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.

The same is true for any later release, too. A single release of Python
2.5.2 will result in many Debian installations, for example. Still,
the *ratio* of the downloads is quite informative, since the same
factors apply to both branches.

In the specific case, we know that Debian provides 2.5.2, but not 2.4.5,
as they avoid integrating newer releases out of fear for new features,
and selectively only pick the security patches. So I can cite at least
one large multiplicator product which *doesn't* want new maintenance
branch releases, but wants explicit identification of security patches
only. I recall people from Redhat saying the same thing.

>> 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.

No, it was discussed months in advance, and had been followed at least
for the 2.3 release (the final 2.2 release occurred even before 2.3).
2.3.5 states, on its web page, that it is the final release of 2.3.

> 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).

Right. Therefore, I circulated a PEP proposing such a strategy in
May 2007.

> 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.

I agree with that. Unfortunately, my PEP didn't get much feedback at
that time.

Regards,
Martin