rfc:php7_57_roadmap

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:php7_57_roadmap [2014/11/22 03:31] pajoyerfc:php7_57_roadmap [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 17: Line 17:
    * within a year    * within a year
    * within 1.5 years    * within 1.5 years
- +   * Whether or not to have a 5.7 release
-additionally we have to decide whether or not we want to release PHP 5.7 as well, no matter when PHP 7 will be released. +
  
 ==== PHP 7, within one year maximum ==== ==== PHP 7, within one year maximum ====
  
-===== Introduction =====+=== Introduction ===
  
 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. 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.
Line 29: Line 27:
  
  
-===== Proposal =====+=== 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.  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. 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.
Line 46: Line 44:
  
  
-===== PHP 7, within one and a half year maximum =====+==== PHP 7, within one and a half year maximum ====
  
-===== Introduction =====+=== 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.  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. 
Line 54: Line 52:
 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. 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.
  
-===== One and year development and 5.7 ===== +=== Proposal ===
- +
-   * Major versions are an unique opportunity to cleanup our code base +
-   * 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. +
-   * There are a couple of major features that are long due, RFCs are in progress +
- +
-===== 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. 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.
Line 68: Line 59:
  
 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. 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. This is why it is critical, if not vital, to do not hurry up and be sure we do it right.
  
-====== Timetable ======+Keys point: 
 +   * Major versions are an unique opportunity to cleanup our code base 
 +   * 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. 
 +   * 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)
 <code> <code>
-**** pre release phase 
-++++ release lifetime with all bug fixes, no feature addition 
----- release lifetime security  fixes only 
-D    EOL 
 Version Time -> Version Time ->
        2014  2015                                                                    2016        2014  2015                                                                    2016
-       Now   Jan   Feb   Mar   Apr   May   Jun   Jul   Aug   Sept  Oct   Nov   Dec   Jan   Feb   Mar   Apr   May   Jun +       Now   Jan   Feb   Mar   Apr   May   Jun   Jul   Aug   Sept  Oct   Nov   Dec   Jan  
-        |                     |                                                     | +        |                                                     |  
-Dev     ++++++++++++++++++++++++ +Dev     +++++++++++++++++++ 
-1st beta                        |++++++++++++++++++++++++++++++ +1st beta                  |++++++++++++++++++++++++ 
-RCs 7                                                         |++++++++++++++++++ +RCs 7                                              |+++++++++++++++++++++++++++++ 
-5.7RC                                                        (*) +5.7RC                                              (*) 
-5.7final                                                              (*) +5.7final                                                    (*) 
-5.7final                                                                       (*)+7 final                                                                        (*)
 </code> </code>
 +
 +=== 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.
 +
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
rfc/php7_57_roadmap.1416627095.txt.gz · Last modified: 2017/09/22 13:28 (external edit)