rfc:php56timeline
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:php56timeline [2015/12/07 12:01] – Initial draft zeev | rfc: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: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== 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:// | The release of PHP 7.0 is the first time a major version of PHP is released under the new [[https:// | ||
The [[http:// | The [[http:// | ||
- | - 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 | + | - 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. | ||
===== 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. | ||
- | This RFC provides | + | This RFC recommends to extend the Active Support period to a full year, followed by two additional years of Security Support. |
- 1 year of Active Support (ending Dec 31, 2016), plus 2 years of Security Support (ending Dec 31, 2018). | - 1 year of Active Support (ending Dec 31, 2016), plus 2 years of Security Support (ending Dec 31, 2018). | ||
Line 26: | Line 31: | ||
- No change - 8 months of Active Support (ending Aug 28, 2016), plus 1 year of Security Support (ending Aug 28, 2017). | - No change - 8 months of Active Support (ending Aug 28, 2016), plus 1 year of Security Support (ending Aug 28, 2017). | ||
- | We believe that option #2 is the least we should | + | There are two main downsides to pushing the support dates for PHP 5.6: |
+ | * 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. | ||
+ | |||
+ | That said, many believe that sticking with the current timeline (option #3) is simply too aggressive, and we should | ||
+ | |||
+ | Further, given the 5.6 -> 7.0 upgrade is more difficult and time consuming - **the recommendation | ||
===== Future Scope ===== | ===== 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. | 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. | ||
+ | |||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | - 1 year of Active Support + 2 years of Security Support | + | - Extend the lifetime of PHP 5.6 yes/no |
- | | + | - If you chose to extend it, extend it to |
- | - 8 months | + | * 1 year of Active Support + 2 years of Security Support |
+ | | ||
+ | |||
+ | In case the majority chooses to extend the lifetime of PHP 5.6 (> | ||
+ | |||
+ | ===== Vote ===== | ||
+ | Voting ends at January 13th, 2016 at 10am GMT. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
- | The option winning the majority of the votes would win. | + | \\ |
+ | \\ | ||
+ | **ONLY IF YOU CHOSE ' | ||
+ | <doodle title=" | ||
+ | * 1 year Active Support \\1 year Security Support | ||
+ | * 1 year Active Support \\2 years Security Support | ||
+ | </ |
rfc/php56timeline.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1