"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. _______________________________________________ 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
