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 the beta period, Release Candidates, and Bug Fix releases.
The number of pre-releases also seems unnecessarily long, especially during the Release Candidate stage, where there are few Release Candidate specific changes.
This RFC aims to address the above issues and proposes to introduce the following changes to the release cycle:
Feature freeze is supposed to happen when we start making beta releases, but this does not always happen.
Right now, at the end of the alpha period, all RFCs targeting that version must have voting finished, but the implementation is frequently necessarily done during the beta period.
RFC implementations are often those that can have a major impact on API and ABI stability.
It therefore seems illogical to allow RFC-requiring features to be merged during the beta period, but not minor improvements that do not require an RFC, such as adding constant, parameters, config options, or even small functions or methods.
We propose to explicitly allow minor features, optimizations, and internal API / ABI changes, during the beta period.
The recommendation is to not accept extensive refactoring, but this would not be a hard requirement, and Release Managers must approve any such small feature during the beta period, as is already the case.
A similar rule was in effect during the PHP 8.3 release cycle, and it worked well.
Currently, we allow exceptions for small self-contained feature additions.
This is often a source of confusion because it is hard to define what a “small self-contained feature” is. An example of such a small feature is the addition of a constant.
The problem with allowing small features, is that it creates a precedent for other (larger) features to be included as well.
It might be also hard for users to find if a feature is available, and they might have to add an explicit check in their code. This can also get confusing in UPGRADING and documentation.
We propose to drop this small feature exception, and disallow any feature addition in Release Candidates, Bug Fix releases, and of course, Security releases.
The release cycle is too long, so we propose to reduce the number of RCs by 2, resulting in only 4 RCs if everything goes according to plan. This should be more than enough, and if there is any problem found, additional RCs can be created if needed. This reduces the release cycle by one month, allowing for this month to be used for normal development of the language.
This change will extend release cycle to 4 years: 2 years of bug fixes, and 2 years of security fixes.
The idea is that it will give users longer support with a relatively small effort, as it doesn't require that much time for RMs. Security releases are not that often and relatively easy.
The proposal does not include the updating of ABI incompatible versions of dependent libraries provided for Windows builds as this can add significantly more load.
This 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 the job of distributions to handle.
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 later in the cycle. These fixes might potentially introduce regressions. If such a regression is found within a year, then it will be possible to apply a fix for that even if the branch allows only security fixes.
Right now, PHP comes out of normal or security release 2 or 3 years after the first GA release. This means that the date shifts around, which is hard to keep track of. We propose to align the end of bug fix and security releases with the end of the year, December 31st.
If a GA was delayed until early in a new year due to issues found during the release candidate period, then the December 31st end date would not move a whole new year further.
If all the proposals are accepted, the new cycle for PHP 8.4 will then look like the following, pushing the start from Jun 6th 2024, to July 4th 2024:
The changes will apply immediately on the all currently supported branches from PHP 8.2. It also means that PHP 8.1 would get an extra year of security fixes if the proposal is accepted.
A normal 2/3rd majority vote for each of the proposed changed.
If any of the proposed changes passes, the Release Process policy document will be updated with any accepted changes, and currently operating rules.
Voting runs until Monday April 29th, at noon UTC.
The implementation of this RFC is a change to the https://github.com/php/policies/blob/main/release-process.rst document.
Keep this updated with features that were discussed on the mail lists.