[Python-Dev] Draft PEP: Maintenance of Python Releases

["Martin v. Löwis"]

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 <martin at v.loewis.de>
Discussions-To: <python-dev at 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: