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 04:02] pajoyerfc:php7_57_roadmap [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 12: Line 12:
  
  
-==== Proposals ====+===== 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:
  
Line 19: Line 19:
    * Whether or not to have a 5.7 release    * Whether or not to have a 5.7 release
  
-===== 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 27: 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 44: 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 52: 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.
  
-====== Proposal ======+=== 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 72: Line 72:
  
  
-====== Timetable ======+=== Timetable ===
     * Dev and beta allow new features to be added, if accepted via RFCs.     * Dev and beta allow new features to be added, if accepted via RFCs.
     * RC means no new feature, even if accepted via RFCs.     * RC means no new feature, even if accepted via RFCs.
Line 89: Line 89:
 </code> </code>
  
-===== PHP 5.7 =====+=== PHP 5.7 ===
  
 The idea of a PHP 5.7 is: The idea of a PHP 5.7 is:
rfc/php7_57_roadmap.1416628940.txt.gz · Last modified: 2017/09/22 13:28 (external edit)