PHP 5.6 Support Timeline

• Version: 0.9
• Date: 2015-12-07
• Author: Zeev Suraski, zeev@php.net
• Status: Draft
• First Published at: http://wiki.php.net/rfc/php56timeline

The release of PHP 7.0 is the first time a major version of PHP is released under the new 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 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:

1. 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.
2. 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.

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.

Several proposals

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.

Include these so readers know where you are heading and can discuss the proposed voting options.

State whether this project requires a 2/3 or 50%+1 majority (see voting)

Links to any external patches and tests go here.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

Make it clear if the patch is intended to be the final patch, or is just a prototype.

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.