rfc:php56timeline

Differences

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

Link to this comparison view

Next revision		Previous revision
rfc:php56timeline [2015/12/07 11:34] – created zeevrfc:php56timeline [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== PHP 5.6 Support Timeline ======+====== PHP 5 Support Timeline ======
   * Version: 0.9   * Version: 0.9
   * Date: 2015-12-07   * Date: 2015-12-07
   * Author: Zeev Suraski, zeev@php.net   * Author: Zeev Suraski, zeev@php.net
-  * Status: Draft+  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/php56timeline   * First Published at: http://wiki.php.net/rfc/php56timeline
  
  
 ===== Introduction ===== ===== Introduction =====
 +
 +This RFC proposes to extend the End of Active Support & End of Security Support dates for PHP 5.6, the final version in the PHP 5 family.
 +
 +===== Background =====
 +
 The release of PHP 7.0 is the first time a major version of PHP is released under the new [[https://wiki.php.net/rfc/releaseprocess|Release Process RFC]].  While the RFC did outline rules for major versions, most of the discussion prior to the RFC, as well as all of the experience we've gained on the ground since its introduction dealt with how we deal with minor versions, as back then a major version wasn't actively being discussed.  In addition, the release of PHP 7.0 happened substantially later than the 'standard' mid-year release cycle that most prior versions of PHP adhered to. The release of PHP 7.0 is the first time a major version of PHP is released under the new [[https://wiki.php.net/rfc/releaseprocess|Release Process RFC]].  While the RFC did outline rules for major versions, most of the discussion prior to the RFC, as well as all of the experience we've gained on the ground since its introduction dealt with how we deal with minor versions, as back then a major version wasn't actively being discussed.  In addition, the release of PHP 7.0 happened substantially later than the 'standard' mid-year release cycle that most prior versions of PHP adhered to.
  
 The [[http://php.net/supported-versions.php|currently published timeline for PHP 5.6]] suggests an end to active support on August 28, 2016 and end to security support on August 28, 2017 - approximately 8 months & 20 months (respectively) after the release of PHP 7.0.  Many consider these timeline inadequate for two key reasons: The [[http://php.net/supported-versions.php|currently published timeline for PHP 5.6]] suggests an end to active support on August 28, 2016 and end to security support on August 28, 2017 - approximately 8 months & 20 months (respectively) after the release of PHP 7.0.  Many consider these timeline inadequate for two key reasons:
  
-  - In absolute terms, 20 months to upgrade the entire worldwide PHP codebase - after which an app that wasn't migrated would be exposed to security vulnerabilities - simply appears to be on the short side.+  - In absolute terms, 20 months to upgrade the entire worldwide PHP codebase - after which an app that wasn't migrated would be exposed to security vulnerabilities - appears to be on the short side.
   - In relative terms, it seems awkward that people would have more time to upgrade from PHP 5.5 to 5.6 - an upgrade that is typically completely painless - than they do to upgrade from 5.6 to 7.0 - an upgrade which requires certain levels of code auditing and extensive testing.   - In relative terms, it seems awkward that people would have more time to upgrade from PHP 5.5 to 5.6 - an upgrade that is typically completely painless - than they do to upgrade from 5.6 to 7.0 - an upgrade which requires certain levels of code auditing and extensive testing.
  
 +In addition, PHP 7 breaks source-level compatibility with PHP 5.x - which means extensions will not work (or even build) on PHP 7 without substantial refactoring.  This refactoring typically amounts to much more than just fixing some compilation errors, due to fundamental changes to the underlying data structures of the engine.  Extending the support period for PHP 5 will allow users of custom extensions - as well as PECL extensions which haven't yet been upgraded - to have more time to port and test them, as well as their code that uses them.  It's worth noting that much of the development effort of PHP 7 since the introduction of the PHPNG engine was focused around porting extensions to build and work on PHP 7 - this is not an easy task.
  
 ===== Proposal ===== ===== Proposal =====
-It is proposed to reschedule both the End of Active Support and End of Security Support to provide the PHP userbase a longer, but still clear upgrade timeline.+It is proposed to reschedule both the End of Active Support and End of Security Support to provide the PHP userbase a longer, but still clear upgrade timeline.  Most people feel that it is more important to further push the End of Security Support date, compared to the End of Active Support date.
  
-Several proposals +This RFC recommends to extend the Active Support period to a full year, followed by two additional years of Security Support.  In total, it provides three different options to choose from:
  
-===== Future Scope ===== +  - 1 year of Active Support (ending Dec 31, 2016), plus 2 years of Security Support (ending Dec 31, 2018). 
-It is recommended that the Release Process RFC be amended to align the End of Support dates for a given version to the release of subsequent versions, also for minor releases.  This is outside the scope of this RFC - which deals specifically with the support timelines of PHP 5.6.+  - 1 year of Active Support (ending Dec 31, 2016), plus 1 year of Security Support (ending Dec 31, 2017). 
 +  - No change - 8 months of Active Support (ending Aug 28, 2016), plus 1 year of Security Support (ending Aug 28, 2017).
  
-===== Proposed Voting Choices ===== +There are two main downsides to pushing the support dates for PHP 5.6: 
-Include these so readers know where you are heading and can discuss the proposed voting options.+  * Obviously, it will require the developers of PHP (us) to maintain it for a longer period of time, investing more time and effort than we would otherwise have to. 
 +  * Extending the end of support dates may reduce the sense of urgency of people to upgrade, and may cause people who would have otherwise upgraded sooner to upgrade later.
  
-State whether this project requires a 2/3 or 50%+1 majority (see [[voting]])+That said, many believe that sticking with the current timeline (option #3) is simply too aggressive, and we should at least go for option #2 as it gives people at least the same amount of time they had to upgrade from 5.5 to 5.6, to upgrade from 5.6 to 7.0.
  
-===== Patches and Tests ===== +Further, given the 5.6 -> 7.0 upgrade is more difficult and time consuming - **the recommendation of this RFC is to go with option #1**.  The importance of giving users a bit more time to upgrade was also alluded to in the [[https://wiki.php.net/rfc/php57|PHP 5.7 RFC]], although it was rejected - mainly due to concerns about defocusing the efforts of releasing PHP 7.0 - concerns which are no longer relevant now that 7.0 has been successfully released. 
-Links to any external patches and tests go here.+ 
 +===== Future Scope ===== 
 +Several people recommended that the Release Process RFC be amended to align the End of Support dates for a given version to the release of subsequent versions, also for minor releases.  This is outside the scope of this proposal - which deals specifically with the support timelines of PHP 5.6 - and would be proposed in a separate RFC. 
 + 
 + 
 +===== Proposed Voting Choices ===== 
 +  - Extend the lifetime of PHP 5.6 yes/no 
 +  - If you chose to extend it, extend it to  
 +    * 1 year of Active Support + 2 years of Security Support 
 +    * 1 year of Active Support + 1 year of Security Support
  
-If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.+In case the majority chooses to extend the lifetime of PHP 5.6 (>50%) - then the option garnering more votes between the two proposed timelines would win.
  
-Make it clear if the patch is intended to be the final patch, or is just a prototype.+===== Vote ===== 
 +Voting ends at January 13th, 2016 at 10am GMT.
  
-===== Implementation ===== +<doodle title="Extend the support timeline of PHP 5?" auth="zeev" voteType="single" closed="true"> 
-After the project is implemented, this section should contain  +   * Yes 
-  - the version(s) it was merged to +   * No 
-  - a link to the git commit(s) +</doodle>
-  - a link to the PHP manual entry for the feature+
  
-===== References ===== +\\  
-Links to external references, discussions or RFCs+\\  
 +**ONLY IF YOU CHOSE 'YES' ABOVE:**
  
-===== Rejected Features ===== +<doodle title="Extend the support timeline to:" auth="zeev" voteType="single" closed="true"> 
-Keep this updated with features that were discussed on the mail lists.+   * 1 year Active Support \\1 year Security Support 
 +   * 1 year Active Support \\2 years Security Support 
 +</doodle>
rfc/php56timeline.1449488081.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools