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

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