rfc:release_cycle_update
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:release_cycle_update [2023/11/05 22:18] – Update bukka | rfc:release_cycle_update [2024/04/09 10:41] (current) – derick | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Your Title Here ====== | + | ====== PHP RFC: Release cycle update |
- | * Version: 0.1 | + | * Version: 0.2 |
- | * Date: 2023-11-05 | + | * Date: 2024-03-21 |
- | * Author: Jakub Zelenak, | + | * Authors: Jakub Zelenka <bukka@php.net>, Derick Rethans < |
- | * Status: | + | * Status: |
===== Introduction ===== | ===== Introduction ===== | ||
- | The current release cycle has been introduced in 2010 by [[rfc: | + | The current release cycle has been introduced in 2010 by [[rfc: |
+ | 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 | ||
+ | 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 | ||
+ | where there are few Release Candidate | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | This RFC proposes following changes to the release cycle. | + | This RFC aims to address the above issues and proposes |
- | ==== Extending security support by one year ==== | ||
- | This is a straight forward change | + | ==== Allow features |
- | The proposal does not include | + | Feature freeze |
- | ==== Allowing recent regression fixes during | + | 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 | ||
- | 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 | + | RFC implementations are often those that can have a major impact on API and ABI stability. |
- | ==== Disallowing new features | + | It therefore seems illogical to allow RFC-requiring |
+ | 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. | ||
- | Currently there is an exception that allows a room for exceptions on a case by case basis and only for small self contained | + | We propose to explicitly allow minor features, optimizations, |
+ | beta period. | ||
- | This proposes | + | The recommendation is to not accept extensive refactoring, |
+ | Release Managers must approve | ||
- | ==== Allow feature that do not require RFC in beta ==== | + | A similar rule was in effect during the PHP 8.3 release cycle, and it worked well. |
- | 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. | + | ==== Disallow New Features in Release Candidates |
- | It should be noted that this rule has been already applied | + | Currently, we allow exceptions |
- | ==== Reduce number | + | This is often a source |
+ | An example of such a small feature is the addition of a constant. | ||
- | 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 | + | The problem |
+ | be included as well. | ||
- | ===== Proposed PHP Version(s) ===== | + | 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. | ||
- | 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 | + | We propose |
+ | Bug Fix releases, and of course, Security releases. | ||
+ | ==== Reduce number of RCs to Four ==== | ||
- | ===== Open Issues | + | The release cycle is too long, so we propose to reduce the number of RCs by 2, resulting in only 4 RCs if everything |
- | Make sure there are no open issues when the vote starts! | + | 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' | ||
+ | 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' | ||
+ | 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 | ||
+ | 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. | ||
- | ===== Future Scope ===== | ||
- | This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. | ||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | Standard separate | + | A normal 2/3rd majority |
+ | |||
+ | If any of the proposed changes passes, the [[https:// | ||
+ | will be updated with any accepted changes, and currently operating rules. | ||
+ | |||
+ | Voting runs until **Monday April 29th, at noon UTC**. | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
+ | |||
+ | The implementation of this RFC is a change to the https:// | ||
===== References ===== | ===== References ===== | ||
- | https:// | + | * Original Release Process RFC: https:// |
+ | * Existing Release Process Policy document: https:// | ||
===== Rejected Features ===== | ===== Rejected Features ===== | ||
Keep this updated with features that were discussed on the mail lists. | Keep this updated with features that were discussed on the mail lists. |
rfc/release_cycle_update.1699222700.txt.gz · Last modified: 2023/11/05 22:18 by bukka