Now that phpng has been merged to master, the way to php 7 is open. However there are many other points that need to be cleared before a final release can be done. Many feature developments have been suspended because of phpng, which was a moving target until now.
PHP major release is an unique opportunity to do a lot of things not possible in minor releases. Code cleanup, refactoring, adding new major features, etc. All these tasks cannot be done in minor releases and the work we do for a major release, and how we do it, define how PHP will look like for the next decade.
As this time there are two positions about when we should try to release php 7 final:
With key decisions about both the version number and the engine for PHP 7 behind us, it's time to define an agreed-upon timeline so that all contributors can align around it. The purpose of this RFC is to define a one year timeline for the delivery of PHP 7.0, with a projected release date of November 2015.
As the competitive landscape for PHP is evolving, the proposal is to shorten that timeline as much as possible while still taking advantage of the unique opportunities available to us due to the major version number change. A one year timeline will allow us a fair amount of time to work on changes that are only allowed in major versions - namely, ones that break compatibility. Arguably, while we should definitely take the opportunity to implement compatibility-breaking changes in 7.0, we also shouldn't turn it into a compatibility-breaking festival, as the more we break, the more likely it is users would delay upgrades, stay with old, insecure versions - or even consider other alternative options. RFCs that don't explicitly require a major version change (i.e., ones that don't break compatibility) - can also be proposed, but they should be secondary, as they can equally make it into future minor versions (7.1, 7.2, etc.).
| Proposed Milestones | ||
|---|---|---|
| Milestone | Timeline | Comment |
| 1. Line up any remaining RFCs that target PHP 7.0. | Now - Mar 15 (4+ additional months) | We're already well under way with doing that, with the PHPNG, AST, uniform variable syntax, etc. |
| 2. Finalize implementation & testing of new features. | Mar 16 - Jun 15 (3 months) | |
| 3. Release Candidate (RC) cycles | Jun 16 - Oct 15 (3 months) | Subject to quality! |
| 4. GA/Release | Mid October 2015 | Subject to quality! |
It's worth noting that the 3rd and 4th milestones will be quality dependent. If we have evidence that suggests that PHP 7 isn't sufficiently mature to go into the RC stage in June, or GA in October - we should of course adjust the timeline accordingly, and not push out a half-baked release. However, the goal would be to stick as much as possible to the deadline of new going-into-7.0 RFCs, and strive to follow the timelines for the 2nd and 3rd milestones as much as possible, to ensure an October 2015 release of PHP 7.0.
PHP 6 was one of the biggest trauma in the php.net history. We have magisterially failed to define a clear roadmap, to find consensus on what it should be along many other issues like small groups fighting each other or hidden meetings or developments.
Most of these issues have been solved or can be solved with the RFC process. However the increasing pressure on PHP from the various alternative implementations (hhvm on top) puts us in a difficult position, and we may better have to act quickly to provide a better or similar alternative.
The release process clearly defines how a release development phase should be done. Being strict allows us to actually release any version in time, as planed. A clear roadmap defining until when RFCs can be proposed, when they have to be implemented and merged, etc prevents any delay.
It is important to keep in mind that only 5.4 has managed to respect it. 5.5 suffers from the opcache introduction, delaying it by 3-4 months. And it was only a simple bundle. However its stability was far away from what was told, bringing any kind of surprises, some of them being still not solved. phpng is by far more complex and brings a lot of changes, many APIs changes in existing functions, most of them are hard to detect automatically.
There are also a couple of features not twenty that are long due. For example, big integer supprt, AST, other like getter/setter, unicode string class annotation may resurface. Some of them can only be done in a major version due to possible BC breaks or too large changes to be done in a minor version (argument used against the int64 patch in 5.x, f.e.). Many of them are closed to be finished but will require time to get stable, just like the new engine.
Also the idea here is not to force us to release in one and half year, there is no reason to wait if we are ready. But we cannot afford to post pone release releases dates as it always leads to more delay, again and again, recent additions like opcache in 5.5 shows it. 5 months later than planed, and it was “only” one extension, PHPNG is a total rewamp.
This is why it is critical, if not vital, to do not hurry up and be sure we do it right.
Keys point:
Version Time ->
2014 2015 2016
Now Jan Feb Mar Apr May Jun Jul Aug Sept Oct Nov Dec Jan
| | | | | | | | | | | | | |
Dev +++++++++++++++++++
1st beta |++++++++++++++++++++++++
RCs 7 |+++++++++++++++++++++++++++++
5.7RC (*)
5.7final (*)
7 final (*)
The idea of a PHP 5.7 is:
It is clear that we may need a 5.7 to add the necessary notices or deprecation notices to prepare our users to move to 7. We also have to be strict and realistic about what we want in 5.7. One of the fears is that we will waste our precious resources on 5.7 instead of 7. It will not happen if we are very clear about 5.7 goals, prepare to 7.
No impact on existing extensions, code, etc. This is purely a planing RFC.
TBD
The RFC is considered approved with 50%+1 acceptance.
TBD
TBD