This PEP attempts to formalize the existing practice, but goes beyond
it in introducing security releases. The addition of security releases
addresses various concerns I heard over the last year about Python
being short-lived. Those concerns are typically raised by Linux
distributors which see that they have to maintain Python releases
much longer than python-dev does, and are now concerned about the
manpower and Python expertise they need.
When looking in detail, they are primarily concerned with security
fixes. They will not add new features to old releases, and they can
ignore bug fixes, but they cannot ignore security fixes. So what
I really think they want is some form of commitment that security
fixes are still considered for a much longer period of time.
In discussions, people often consider "short-lived" as "shorter
than five years". So the PEP proposes to produce security releases
for five years after the initial release; this would mean that
we are willing to make security releases for 2.3 (until July 2008)
and 2.4 (until November 2009). To reduce the work-load, the PEP
promises no more than one security release per branch per year
(if no security fixes get contributed, no release needs to be
made).
Notice that this setup significantly relies on *no*
bug fixes (other than security fixes) being committed to a branch after
the final bugfix release. Addition of bug fixes would require much
more extensive testing, with release candidates and everything, so
it is essential that there are very very few new patches in each
security release.
Please let me know what you think.
Regards,
Martin
PEP: XX
Title: Maintenance of Python Releases
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis
From time to time, security releases will be made from an unmaintained branch. A security release will be a source-only release (i.e. no Windows or Macintosh binaries are provided); they will follow the numbering of minor releases (i.e. x.y.z).
Security releases should be made at most one year after a security patch has been committed to the branch; users wishing to deploy security patches earlier can safely export the maintenance branch, or otherwise incorporate all committed security fixes into their code base. Security releases should be made for a period of five years after the initial major release. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: