httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zuelke>
Subject A new release process?
Date Fri, 30 Dec 2016 04:16:11 GMT
Hi everyone,

Given the several current threads where there's arguing about what and how and when to release
features, backported or not, I'd like to offer a tale of a project that was, more or less,
in the same dire spot, and pulled itself out of that misery with great success and universal

That project is PHP.

Back in 2010, it was stuck at version 5.3.something, there was no standards around what feature
goes into a minor release, how a feature is even accepted for inclusion, how security updates
were treated, and so forth.


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.

This makes for very predictable update cycles, and for pretty easy updating, as it's very
very unusual that a x.y.z release breaks existing behavior. At the same time, since x.y.0
releases are made roughly once a year, bigger changes do not exist in a limbo branch forever,
but will see the light of day eventually (and, again, after a predictable amount of time).
There is a defined roadmap with active/security maintenance status and EOL dates for all versions;

From a user perspective, this change has been fantastic. Once virtually stagnant, development
of the language itself has been much more active; users have a much better idea up front around
when fixes or features will land; upgrades have become easy as there are clear definitions
of what kind of changes a version may contain.

But most importantly, the language itself has seen a steady flow of new features as a result
from this discipline. For features and bigger changes, an RFC is written with rationale, analysis,
suggestion of implementation, and then it can be voted on. Once accepted, it can be committed,
reviewed, and merged. Even for "outside" contributors, this process is transparent, and the
mental threshold towards contribution has been lowered greatly, as acceptance of an RFC basically
means that the feature will go into a new release anywhere between within a few months and
a year and a bit (depending on when in the release cycle it happens).

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.

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. 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. Then a backport goes wrong (still using SVN,
in my opinion, does not help there, but that's a whole different discussion :)), 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!


View raw message