rfc:php56timeline

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:php56timeline [2015/12/09 08:34] – Fix PHP 5.7 RFC link zeevrfc:php56timeline [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 3: Line 3:
   * Date: 2015-12-07   * Date: 2015-12-07
   * Author: Zeev Suraski, zeev@php.net   * Author: Zeev Suraski, zeev@php.net
-  * Status: Under discussion+  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/php56timeline   * First Published at: http://wiki.php.net/rfc/php56timeline
  
Line 20: Line 20:
   - 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 =====
Line 34: Line 35:
   * 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.   * 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, we 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.+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.
  
-Further, given the 5.6 -> 7.0 upgrade is more difficult and time consuming - **our recommendation is 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.+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.
  
 ===== Future Scope ===== ===== Future Scope =====
Line 49: Line 50:
  
 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. 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.
 +
 +===== Vote =====
 +Voting ends at January 13th, 2016 at 10am GMT.
 +
 +<doodle title="Extend the support timeline of PHP 5?" auth="zeev" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
 +\\ 
 +\\ 
 +**ONLY IF YOU CHOSE 'YES' ABOVE:**
 +
 +<doodle title="Extend the support timeline to:" auth="zeev" voteType="single" closed="true">
 +   * 1 year Active Support \\1 year Security Support
 +   * 1 year Active Support \\2 years Security Support
 +</doodle>
rfc/php56timeline.1449650054.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools