rfc:php7_57_roadmap
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
rfc:php7_57_roadmap [2014/08/15 13:55] – pajoye | rfc:php7_57_roadmap [2014/11/23 02:28] – Fixed heading levels ajf | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Version: 0.1 | * Version: 0.1 | ||
* Date: 2014-08-15 | * Date: 2014-08-15 | ||
- | | + | |
* Status: Draft | * Status: Draft | ||
* First Published at: https:// | * First Published at: https:// | ||
Line 10: | Line 10: | ||
PHP major release is an unique opportunity to do a lot of things not possible in minor releases. Code cleanup, refactoring, | PHP major release is an unique opportunity to do a lot of things not possible in minor releases. Code cleanup, refactoring, | ||
- | |||
- | This is why it is critical, if not vital, to do not hurry up and be sure we do it right. | ||
- | ===== Proposal | + | ===== Proposals |
As this time there are two positions about when we should try to release php 7 final: | As this time there are two positions about when we should try to release php 7 final: | ||
- | * within a year, no php 5.7 | + | * within a year |
- | * within 1.5 to 2 years, with 5.7 | + | * within 1.5 years |
+ | * Whether or not to have a 5.7 release | ||
- | ===== One and half year development and no 5.7 ===== | + | ==== PHP 7, within one year maximum |
- | * no risk to reproduce what happened with the php 6 | + | === Introduction === |
- | * Keep our limited resources on one release | + | |
- | * There are enough new features in phpng to justify a major version | + | |
- | * cleanups can be done later | + | |
+ | 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. | ||
- | ===== One and year development | + | |
+ | === Proposal | ||
+ | |||
+ | 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. | ||
+ | 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 | ||
+ | | 1. **Line up any remaining RFCs that target PHP 7.0.** | ||
+ | | 2. **Finalize implementation & testing of new features.** | Mar 16 - Jun 15 (3 months) | | | ||
+ | | 3. **Release Candidate (RC) cycles** | ||
+ | | 4. **GA/ | ||
+ | |||
+ | |||
+ | 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, | ||
+ | |||
+ | |||
+ | ==== PHP 7, within one and a half year maximum | ||
+ | |||
+ | === Introduction === | ||
+ | |||
+ | 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. | ||
+ | |||
+ | === Proposal === | ||
+ | |||
+ | 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, | ||
+ | |||
+ | There are also a couple of features not twenty that are long due. For example, big integer supprt, AST, other like getter/ | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | This is why it is critical, if not vital, to do not hurry up and be sure we do it right. | ||
+ | |||
+ | Keys point: | ||
* Major versions are an unique opportunity to cleanup our code base | * Major versions are an unique opportunity to cleanup our code base | ||
* Major versions dictate what PHP will be in the next decade or more | * Major versions dictate what PHP will be in the next decade or more | ||
- | * It is unrealistic to consider than less than a year is enough to understand, stabilize and release a phpng based major version. | + | * It is unrealistic to consider than less than a year is enough to understand, stabilize and release a phpng based major version. |
- | * There are a couple of major features that are long due, RFCs are in progress | + | * There are a couple of major features that are long due, RFCs are in progress |
+ | |||
+ | |||
+ | |||
+ | === Timetable === | ||
+ | * Dev and beta allow new features to be added, if accepted via RFCs. | ||
+ | * RC means no new feature, even if accepted via RFCs. | ||
+ | * Anything not stable enough for the 1st RC, or blocking for final, may be removed from the release, based on core devs decision (maybe quick votes and such, consensus or RMs decision for smaller features) | ||
+ | < | ||
+ | Version Time -> | ||
+ | | ||
+ | | ||
+ | | | ||
+ | Dev | ||
+ | 1st beta |++++++++++++++++++++++++ | ||
+ | RCs 7 |+++++++++++++++++++++++++++++ | ||
+ | 5.7RC (*) | ||
+ | 5.7final | ||
+ | 7 final (*) | ||
+ | </ | ||
+ | |||
+ | === PHP 5.7 === | ||
+ | |||
+ | The idea of a PHP 5.7 is: | ||
+ | * Prepare our users to 7 | ||
+ | * No or very little additions, development must be focused on 7 | ||
+ | * Keep to our release process | ||
+ | |||
+ | 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. | ||
Line 52: | Line 116: | ||
<doodle title=" | <doodle title=" | ||
* One year | * One year | ||
- | * One and half year | + | * One and a half year |
</ | </ | ||
\\ | \\ | ||
- | <doodle title=" | + | <doodle title=" |
* yes | * yes | ||
* no | * no | ||
Line 61: | Line 125: | ||
\\ | \\ | ||
The RFC is considered approved with 50%+1 acceptance. | The RFC is considered approved with 50%+1 acceptance. | ||
- | \\ | ||
- | The vote starts on May 13th 2014 and ends < | ||
- | |||
- | |||
- | |||
===== References ===== | ===== References ===== |
rfc/php7_57_roadmap.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1