This is somewhat orthogonal to Bill's current suggestion. It solves a
different set of problems, more related to the short-term
features-versus-regressions argument and less related to the long-term
ABI arguments. Both are important to me, and I agree with many pieces of
what both Jim and Bill are saying.
(This is a combination of a bunch of different ideas from different
people, on this list and off, so thank you all for discussing.)
== Proposal ==
We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch
line. There are no new features or large code changes to this branch,
there are no refactorings or whitespace changes or huge cleanups; the
only changes that land here are targeted bug fixes to 2.4.25.
2.4.25.x is on a cadence: it's T&R'd like clockwork every month.
Releases from that line still follow the necessary voting procedure.
Meanwhile, once we decide we have enough new features for 2.4.26, we T&R
that. If 2.4.26 releases, and we decide we need some fixes, we spin up a
2.4.26.x branch and move to a cadence on it.
Requirements for a backport to the new low-risk 2.4.25.x branch:
- Your change must have landed in 2.4.x.
- Your change must be linked to a PR for a bug/regression.
- Your change is the smallest/simplest fix necessary (for some
definition of small/simple that your fellow voters agree with).
- You must have a test (or set of tests) committed to the test suite
that proves this change fixes the bug. (I.e. it fails before the change
and succeeds afterwards.)
Three votes are still required, and the commits to the test suite are
part of the voting review. If you can convince three other people that a
test is not worth the effort, you can override this requirement with an
additional vote (four total).
== Why? ==
The even-versus-odd, features-versus-regression idea seemed to have some
traction, but it means that fixes block features during an even release
and, to a certain extent, vice-versa during an odd release.
In this proposal, you have to really be serious about a bug fix to get
it into the patch line -- a double backport plus a mandatory addition to
the test suite -- but you're rewarded by knowing that your change *will*
be T&R'd within the month. And the next feature release won't be blocked
on fixes.
It gives us some emergency flexibility too. God forbid, say the 2.4.26
release introduces some absolute mayhem, we're deadlocked on some
breaking change or massive argument, users don't want to move to 2.4.26
and things are going nowhere fast for 2.4.27. Fine. 2.4.25.x is still
alive as long as there are enough PMC members interested in releasing
from it; the cadence only ends when we decide it does. The downside is
that we then have two parallel "latest" versions for 2.4.x, but if you
can convince three PMC members that this situation is better than being
frozen, so be it.
End users and maintainers should eventually feel, once we work out the
kinks, that the risk of upgrading to 2.4.x.y is never more than the risk
of upgrading to 2.4.x was. We should feel like our releases are never
frozen, even if we disagree about some major new feature -- we can
always fix stuff for users while we argue. The test suite will grow as
long as patch lines are released. And if it gets good enough, some day
far in the future, patch lines will become less and less necessary.
Thoughts?
--Jacob
