PHP RFC: Your Title Here

• Version: 0.1
• Date: 2023-11-05
• Author: Jakub Zelenak, bukka@php.net
• Status: Draft

The current release cycle has been introduced in 2010 by release process RFC. This has been working mostly well but there has been some minor issues with that. The length of cycle is often mentioned as being too short. It is also quite risky introduce more complex fixes later in the cycle as the security support does not allow fixing potential regressions. In addition, it is not exactly clear which features can be introduced during beta, RC and bug fixing releases. And the whole cycle seems unnecessary long especially during RC stage where there are very few RC specific changes.

This RFC proposes following changes to the release cycle.

This is a straight forward change that will extend release cycle to 4 years - 2 years or bug fixes + 2 years of security fixes. The idea is that it will give users longer support with relatively small effort as it doesn't require that much time for RM's - security releases are not that often and are relatively easy.

The proposal does not include updating of ABI incompatible versions of dependent libraries provided for Windows builds as this can add significantly more load so this is excluded. It means that Windows users should track security changes in dependant libraries if they want to keep using PHP in its second year of security support. This is just for Windows as we don't build dependent libraries for Linux and other systems - this is usually distributions job.

This proposal is to allow fixes of regressions caused by other fixes introduced in the last 12 months. The reasoning behind this is that more complex fixes will be possible late in the cycle. Those fixes might potentially introduce regression and iaf such regression is found in a year, then it will be possible to apply a fix for that even if the branch allows only security fixes.

Currently there is an exception that allows a room for exceptions on a case by case basis and only for small self contained features additions. This is often source of confusion because no one can really decide what such feature can be. One usual feature is often constant addition. The problem with that is that it creates sort of precedent for other features. It might be also hard for users to find if the feature is available and they have to add an explicit checks to the code. This can also get confusing in UPGRADING and documentation.

This proposes to drop this feature exception completely and disallow any feature addition in RC and bug fixing releases.

Currently beta is called a feature freeze but effectively it isn't. The main issue with that is that the end of alpha just means that all RFC's targeting that version must have voting finished but the implementation can be done during beta. This is however a major inconsistency because RFC implementations are often those that can have a major impact on API and ABI stability so it seems illogical to allow that but don't allow minor improvements that do not require RFC.

This proposal tries to change that and explicitly allow minor features, optimizations and internal API / ABI changes to be done during beta. The recommendation is to preferably not do extensive refactoring if possible but it is not a requirement.

It should be noted that this rule has been already applied for 8.3 release cycle and it worked very well.

As mentioned above the release cycle is too long so this proposal simply reduces number of RC's by 2 so there will be only 4 RC's be default. That should be more than enough and if there is any problem found, additional RC can be added.

The changes will apply immediately on the all currently supported branches. It has been agreed between release managers that the additional security support will be possible to apply on PHP-8.0. It means that PHP-8.0 would get an extra year of security fixes.

Make sure there are no open issues when the vote starts!

This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

Standard separate vote for each proposed point.

https://wiki.php.net/rfc/releaseprocess

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