rfc:php56timeline
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
rfc:php56timeline [2015/12/07 11:34] – created 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. 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. |
- | ===== Future Scope ===== | + | - 1 year of Active |
- | It is recommended that the Release Process RFC be amended to align the End of Support | + | |
+ | - 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 | + | * 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 | ||
- | State whether this project requires a 2/3 or 50%+1 majority | + | That said, many believe that sticking with the current timeline |
- | ===== 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:// |
- | Links to any external patches | + | |
+ | ===== Future Scope ===== | ||
+ | Several people recommended that the Release Process RFC be amended | ||
+ | |||
+ | |||
+ | ===== 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 | + | In case the majority chooses |
- | 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=" |
- | After the project is implemented, | + | * Yes |
- | - the version(s) it was merged to | + | * No |
- | - a link to the git commit(s) | + | </ |
- | - a link to the PHP manual entry for the feature | + | |
- | ===== References ===== | + | \\ |
- | Links to external references, discussions or RFCs | + | \\ |
+ | **ONLY IF YOU CHOSE ' | ||
- | ===== Rejected Features ===== | + | <doodle title=" |
- | 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 | ||
+ | </ |
rfc/php56timeline.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1