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 <[EMAIL PROTECTED]> Discussions-To: <python-dev@python.org> Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2005 Abstract ======== This PEP defines the policy for the maintenance of release branches for Python. Overview ======== The Python core developers maintain two major branches at any point in time: the trunk, which will eventually become the next major release, and the current release branch, from which bug-fix releases are made. As a special case, the number of branches may duplicate while Python 2.x and Python 3.x is developed in parallel. Older releases of Python see no regular maintenance, however, security flaws will be fixed in older releases, eventually resulting in a security release. Major Releases ============== Major releases are numbered x.y (despite the .y being commonly named "minor" release in other projects). The release process is described in PEP 101. Major releases should be produced roughly every 18 months, but the actual release frequency may vary significantly. With a major release x.y, this release becomes the current release. For the previous current release (x.(y-1)), a final bug fix release is produced shortly after the x.y release. Bugfix Releases =============== Bug fix releases (numbered x.y.z) are described in PEP 6. As stated there, they may only include bug fixes (no new features), and they are produced typically every six months. Bug fixes should be committed to the release branch as an ongoing activity (e.g. along with fixing them in the trunk), rather than being backported just before the release. After the final bug fix release for a branch has been made, the branch becomes unmaintained except for security fixes. No bug fix patches must be applied to the branch. Security Releases ================= As users operate Python releases long after the release branch has become unmaintained, they still like to see security patches fixed. The Python source repository can act as a repository for security fixes even after the branch has become unmaintained. Users wishing to contribute security patches must clearly indicate that a certain patch is a security patch, and to what branches they want to see it applied. Commit messages of security patches on unmaintained branches must indicate that the commit was done for security reasons; an explicit description of potential exploits should be avoided. A security fix must not risk the releasability of the branch, i.e. the maintenance branch should be in a shape to produce a release out of it as-is at all times. >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: _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
