aahz> Starting with Python 2.0, all feature releases are required to
aahz> have the form X.Y; patch releases will always be of the form
aahz> X.Y.Z. To clarify the distinction between a bug fix release and a
aahz> patch release, all non-bug fix patch releases will have the suffix
aahz> "p" added. For example, "2.1" is a feature release; "2.1.1" is a
aahz> bug fix release; and "2.1.2p" is a patch release that contains
aahz> minor feature enhancements.
I don't understand the need for (or fundamental difference between) bug fix
and patch releases. If 2.1 is the feature release and 2.1.1 is a bug fix
release, is 2.1.2p a branch off of 2.1.2 or 2.1.1?
aahz> The Patch Czar is the counterpart to the BDFL for patch releases.
aahz> However, the BDFL and designated appointees retain veto power over
aahz> individual patches and the decision of whether to label a patch
aahz> release as a bug fix release.
I propose that instead of (or in addition to) the Patch Czar you have a
Release Shepherd (RS) for each feature release, presumably someone motivated
to help maintain that particular release. This person (almost certainly
someone outside PythonLabs) would be responsible for the bug fix releases
associated with a single feature release. Your use of 2.1's sre as a "small
feature change" for 2.0 and 1.5.2 is an example where having an RS for each
feature release would be worthwhile. Applying sre 2.1 to the 2.0 source
would probably be reasonably easy. Adding it to 1.5.2 would be much more
difficult (no Unicode), and so would quite possibly be accepted by the 2.0
RS and rejected by the 1.5.2 RS.
As time passes, interest in further bug fix releases for specific feature
releases will probably wane. When interest drops far enough the RS could
simply declare that branch closed and move on to other things.
I envision the Patch Czar voting a general yea or nay on a specific patch,
then passing it along to all the current RSs, who would make the final
decision about whether that patch is appropriate for the release they are
managing.
I suggest dumping the patch release concept and just going with bug fix
releases. The system will be complex enough without them. If it proves
desirable later, you can always add them.
Skip
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