[Python-Dev] Maintaining old releases (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Wed Aug 13 23:37:40 CEST 2008

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

More information about the Python-Dev mailing list