[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