"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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4