PHP releases have always been done spontaneously, in a somehow chaotic way. Individual(s) decided when a release will happen and what could or could fit in. Release managers role are unclear and the way to nominate them is not clearly defined either.
The goals of this RFC aim to solve these issues while giving to us, our users and 3rd parties (distributions, contributors, etc.) more visibility and the ability to actually have a roadmap, or plan developments. This RFC aims to define:
No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis.
Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6. Binary compatibility can be broken between two features releases, f.e. between 5.3 and 5.4:
It is critical to understand the consequences of breaking BC, APIs or ABIs (only internals related). It should not be done for the sake of doing it. RFCs explaining the reasoning behind a breakage and the consequences along with test cases and patch(es) should help.
See the following links for explanation about API and ABI:
**** pre release phase
++++ release lifetime with all bug fixes, no feature addition
---- release lifetime security fixes only
D EOL
Version Time ->
2011 2012 2013 2014 2015 2016 2017
| | | | | | | | | | | | |
5.3 +++++++++++++-----D
5.4 |*****+++++++++++++++++++++++++-----------D
5.5 | | |******++++++++++++++++++++++++-----------D
5.6 | | | | |******++++++++++++++++++++++++-----------D
6.0 | | | | |******++++++++++++++++++++++++-----------D
6.1 | | | | |******++++++++++++++++++++++++-----------D
However it could happen that a new major version is desired while the active major version is still heavily used. Like what we had between php 4 and 5 or for the oldest, between php 3 and 4.
**** pre release phase
++++ release lifetime bugs
---- release lifetime security only
D EOL
Version Time ->
2011 2012 2013 2014 2015 2016 2017
| | | | | | | | | | | | |
5.3 +++++++++++++-----D
5.4 |*****+++++++++++++++++++++++++-----------D | | | | |
5.5 | | |******++++++++++++++++++++++++-----------D | | |
5.6 | | | |******++++++++++++++++++++++++-----------D
6.0 | | |******++++++++++++++++++++++++-----------D | |
6.1 | | | |******++++++++++++++++++++++++-----------D
RFCs have been introduced two years ago and have been proven as being an amazing way to avoid conflicts while providing a very good way to propose new things to php.net. New features or additions to the core should go through the RFC process. It has been done successfully (as the process went well, but the features were not necessary accepted) already for a dozen of new features or improvements.
Features can use branch(es) if necessary, doing so will minimize the impact of other commits and changes on the development of a specific feature (or the other way 'round). The shorter release cycle also ensures that a given feature can get into the next release, as long as the RFC has been accepted.
The change to what we have now is the voting process. It will not happen anymore on the mailing list but in the RFCs directly, for php.net members, in a public way.
See also the voting RFC.
The question for this section is about who will be allowed to vote:
We have voting plugin for dokuwiki (doodle2) that allows voting on the wiki (installed).
The roles of the release managers are about being a facilitator:
But they are not:
Discussions or requests for a feature or to apply a given patch must be done on the public internals mailing list or in the security mailing (ideally using the bug tracker)
The release managers team should be selected in a more transparent way. The ideal way is again to go through a proposal and a vote. The same system than the RFCs can obviously be used for the release managers selection.
The volunteers (a team of two persons) can add propose themselves via the mailing list and they will be added to a RFC page. A week between the last call and the vote should be sufficient (given that anyone can volunteer himself for the next release at any time). The vote takes place for a week.
Examples:
The team with the most votes will be then the RMs for the given release. One person cannot be a RM for more than one release at the same time.
Again, one of the questions for this section is about who will be allowed to vote:
NB: the poll plugin will be installed shortly
Some features require a lot of testing or users feedback before they can be considered as ready, stable enough or proven as having made good design decisions. Having them in normal releases is dangerous. The past releases told us more that once than many good ideas ended as being not so good after all. But we had to keep them in and, even worst, maintain them forever.
A feature preview release could solve this problem. A feature(s) preview release gives us and our users a way to try bleeding edge additions to the language or core while providing us with an invaluable feedback to actually valid both the implementation and the design choices.
Non core features (engine, stream, etc.) could benefit from a feature preview release while doing it via PECL should be the preferred way.
Feature(s) preview releases can happen any time and can be platform specific. Whether a specific development branch is used or not is up to the developers of the given features (external repositories like github or bitbucket can obviously be used as well).
2011/6/20
2011/5/24