PHP RFC: Release cycle update
- Version: 0.2
- Date: 2024-03-21
- Authors: Jakub Zelenka bukka@php.net, Derick Rethans derick@php.net
- Status: Voting
Introduction
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.
Proposal
This RFC aims to address the above issues and proposes to introduce the following changes to the release cycle:
Allow features that do not require an RFC in the beta period
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.
Disallow New Features in Release Candidates and Bug Fix releases
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.
Reduce number of RCs to Four
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.
Extend Security Support by One Year
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.
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 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.
Extend Releases Cycle to End of Year
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.
Revised Timeline
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:
- Jul 04 2024: Alpha 1
- Jul 18 2024: Alpha 2
- Aug 01 2024: Alpha 3
- Aug 13 2024: Feature freeze — All RFCs must have their voting concluded, and *should* have been merged.
- Aug 15 2024: Beta 1
- Aug 29 2024: Beta 2
- Sep 10 2024: RFCs features, and features not requiring an RFC, must be merged (the tagging date for the Sep 12 Beta 3 release) (with approval of RM).
- Sep 12 2024: Beta 3
- Sep 24 2024: Branching of the PHP-8.4 release branch (not a new thing)
- Sep 26 2024: RC 1 — No more new features may be introduced into the 8.4 release from now on.
- Oct 10 2024: RC 2
- Oct 24 2024: RC 3
- Nov 07 2024: RC 4
- Nov 21 2024: GA
- Dec 31 2026: End of Bug Fix Releases — Start of Security Releases
- Dec 31 2027: End of fixing regressions in Bug Fix releases — ABI incompatible versions of dependent libraries on Windows will no longer be updated.
- Dec 31 2028: End of Security Releases
Proposed PHP Version(s)
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.
Proposed Voting Choices
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.
Patches and Tests
The implementation of this RFC is a change to the https://github.com/php/policies/blob/main/release-process.rst document.
References
- Original Release Process RFC: https://wiki.php.net/rfc/releaseprocess
- Existing Release Process Policy document: https://github.com/php/policies/blob/main/release-process.rst
Rejected Features
Keep this updated with features that were discussed on the mail lists.