PHP RFC: Release cycle update
- Version: 0.1
- Date: 2023-11-05
- Author: Jakub Zelenak, email@example.com
- Status: Under Discussion
The current release cycle has been introduced in 2010 by release process RFC. This has been working mostly well but there have been some minor issues. The length of cycle is often mentioned as being too short. It is also quite risky to introduce more complex fixes later in the active support 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 number or pre-releases seems unnecessary long especially during RC stage where there are very few RC specific changes.
This RFC aims to address above issues and proposes to introduce the following changes to the release cycle.
Extending security support by one year
This change 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. 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.
Allowing recent regression fixes during security support
This proposal is to allow fixes of regressions caused by other fixes merged to the supported branch 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 if 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.
Disallowing new features completely in RC and bug fixing release
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.
Allow feature that do not require RFC in beta
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.
Reduce number of RC to 4
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's can be added.
Proposed PHP Version(s)
The changes will apply immediately on the all currently supported branches from PHP-8.1. It means that PHP-8.0 would get an extra year of security fixes if that proposal is accepted.
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.
Proposed Voting Choices
Standard separate vote for each proposed point.
Patches and Tests
Keep this updated with features that were discussed on the mail lists.