On 12/29/2016 08:16 PM, David Zuelke wrote:
The tl;dr of this approach is that
- any x.y.z release only introduces bugfixes. These releases are done
every four weeks, like clockwork. If a fix doesn't make the cut for a
release, it'll end up in the next one; - x.y.0 releases, on the other
hand, may introduce new features, fixes, and deprecations, but no
breaking changes; - x.0.0 releases are the big ones (think PHP 7.0.0
in late 2015). where backward compatibility may be changed, etc.
My favorite pieces here are
- the introduction of a release cadence
- the separation of bugfix releases from feature releases
Both make life easier -- for us, for users, and for intermediate
maintainers -- for the reasons you've mentioned.
[...]
There are a bunch of technicalities that would need adjusting to fit
HTTPD, such as release intervals, release management (for PHP, every
x.y.* series has two managers who jointly coordinate releases), etc,
but overall the idea is, IMO, worth considering.
Our current process is also fairly labor-intensive, so moving to a quick
release cadence without simultaneously fixing that is not likely to end
up well, IMO. There are other discussions on the list for improving our
automated QA, which I think is probably step 1.
As a, more or less, "outside observer", I happen to think that the
current method of voting on finals, instead of a practice of rolling
out RCs (that are then left up for testing for at least a week), is
fundamentally broken. The 2.4 changelog in particular is littered
with releases that were never officially published. For users, that's
really confusing.
To a certain extent I think this is something that people get used to
easily... but for security patches in *particular*, I agree. It's
disconcerting to hear that CVE 2099-BLAH was fixed in 2.4.Z and then
find out that 2.4.Z was never released.
For maintainers, it's painful to start over the
process each time, and it sometimes leads to months and months
without a release that contains certain fixes.
The pain of discarding and restarting your manual tests because someone
else found a regression on another platform two hours into the release
vote comes to mind, yes.
For the record, though, I think having strong automated QA processes
will help both of these issues more than the release cadence will. It's
just that the cadence reinforces the QA and the QA reinforces the
cadence; they go hand-in-hand in a very nice positive feedback loop.
Then a backport goes
wrong (still using SVN, in my opinion, does not help there, but
that's a whole different discussion :)),
I've started some discussions on how we might introduce feature- and
fix-branches, and hopefully better backport workflows, into our current
use of SVN. (I'm a git user myself, and the current backport process is
more error-prone than I'm used to as well. But I have no desire to start
a holy war, and I'm confident we can find an SVN workflow that works well.)
and a regression is in the
latest release until someone eventually picks up a fix.
Much of this, and many of the "what do we backport from trunk" and
"I'd like to squeeze in a change I've had sitting around locally,
please wait with the new release, because who knows when the next one
after that will be" are, from what I can tell, a significant source
of discord on this mailing list. All these unnecessary distractions
that deteriorate personal relationships, while at the same time
slowing down the pace of the project (several people have already
pointed out Nginx's rate of innovation in comparison) and raising the
threshold for contributions, can be fixed. PHP is the perfect
example, and I think HTTPD would be wise to at least consider
following this example.
Happy New Year!
Thanks for your input!
--Jacob
