Python milestone releases

[David Fraser]

Martin v. Löwis wrote:
> Thomas D'Tak wrote:
> 
>> The question is now, how to handle this kind of problems?
> 
> 
> The Python Business Forum once tried to attack the problem
> by planning to release a "Python-in-a-tie" release. This
> release would be maintained essentially forever, and they
> wanted PythonLabs to commit that this release is not
> superceded by another release for atleast a year. Python
> 2.2 was chosen as the basis, and indeed, it lived for 18
> months without a successor. Today, 2.2 is not maintained
> anymore by the "usual" maintainers, which have moved towards
> 2.3 and 2.4. Nobody has taken over maintenance of 2.2,
> from which I conclude there is really no need for ongoing
> maintenance of old releases.
> 
> Now, if your partners are still running Python versions
> too old for your software, the pressure to upgrade should
> come from you, the one who needs the newer version. Python
> supports side-by-side installation of multiple versions,
> so this should cause no problem (except for the disk space,
> of course).
> 
> Regards,
> Martin

What may be easier in some situations is to have back-ported versions of 
new standard modules that will run with previous versions of Python.
For example, Python 2.3 introduces the datetime module ; to require 
people to upgrade from Python 2.2 for a new module seems steep ...

David