Some stuff on Python 2.7.x support periods

March 4, 2012

It figures that shortly after I wrote The (future) problem with Python 2.7, I found out that the Python people had announced a release candidate for what will be Python 2.7.3 when it's released officially. The direct cause of this is likely some security fixes (especially the hash table issue), but it also includes quite a number of other bugfixes.

All of this made me realize that I didn't actually understand the normal Python support periods. The Python people have never made any explicit promises about this, but they have said some things. First off, the 2.7 release notes have a section talking about this, where they comment that two years has been their typical period for bug fixes. The only sensible way to interpret this is that the two years would normally run from the initial release of Python 2.7 on July 4th 2010; this puts the new 2.7.3 release just within the regular 2 year horizon but any likely future release outside it.

(Based on the documentation dates, previous 2.x versions apart from 2.6 have basically had close to a two year lifetime.)

Python 2.6 is an interesting exception to the past support intervals, in that it's still getting security fixes; the 2.6.8 release notes to be says that the Python people intend to provide security fixes for five years (counting from the initial 2.6 release). One could reasonably conclude that the 2.7 support period will be at least as generous. Personally I'm hoping for more generous; five years for security fixes alone would be better than nothing but not ideal. People who are still shipping Python 2.7.x in a few years will want not just security fixes but also fixes for bugs that have been stumbled over by their users.

(Leaving the bugs unfixed as an incentive for people to migrate to Python 3 doesn't work. Given the general issues with such a migration it just causes distributions to patch Python 2.7.x themselves. Linux distributions have very little hesitation about patching upstream software to fix sufficiently important issues; indeed, a declared 'no bugfixes' policy makes it easier in several ways.)

Written on 04 March 2012.
« Two ways I increase the security of SSH personal keys
Convenience in web frameworks is often insecure »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 4 02:17:54 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.