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 acclaim.
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. Enter: https://wiki.php.net/rfc/releaseprocess 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; see http://php.net/supported-versions.php 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! David
