[Python-Dev] Draft PEP: Maintenance of Python Releases (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Sat May 12 15:02:53 CEST 2007

"Martin v. Löwis" writes:

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.

[...]

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.

I don't understand the point of a "security release" made up to a year after commit, especially in view of the first quoted paragraph. A commit may not be made without confirming immediate releasability. Isn't that the painful part of a release? If so, shouldn't an immediate release should be made, and not be that much burden? (At least in my practice, all that's left is an announcement -- which is going to be about 2 lines of boilerplate, since detailed explanations are prohibited -- and rolling tarballs.)

If rolling tarballs etc is considered a burden, a "tag release" could be made. OS distributors are going to import into a vendor branch anyway, what they want is python-dev's certification that it's been checked and (as much as possible given the urgency of a security patch) is safe to apply to their package trees.

More information about the Python-Dev mailing list