httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: A new release process?
Date Tue, 03 Jan 2017 19:32:03 GMT
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!


View raw message