rfc:release_cycle_update

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:release_cycle_update [2023/11/05 21:44] – created bukkarfc: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, bukka@php.net +  * Authors: Jakub Zelenka <bukka@php.net>, Derick Rethans <derick@php.net> 
-  * Status: Draft+  * Status: Voting
  
 ===== Introduction ===== ===== Introduction =====
-The current release cycle has been introduced in 2010 by [[rfc:releaseprocess|release process RFC]]. This has been working mostly well but there has been some reasonable requests for some minor changes over the time. 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 supports 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.+ 
 +The current release cycle has been introduced in 2010 by [[rfc:releaseprocess|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 ===== ===== Proposal =====
  
-This RFC proposes following changes to the release cycle+This RFC aims to address the above issues and proposes to introduce the following changes to the release cycle:
  
-==== Extending security support by one year ==== 
  
-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 give that much load to RM's - security releases are not that often and are relatively easy.+==== Allow features that do not require an RFC in the beta period ====
  
-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 security year support. Preference should be update though. This is just for Windows as we don't build libraries for Linux and other systems - this is usually distribution job.+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 ==== ==== Allowing recent regression fixes during security support ====
  
-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 introduce regression. If such regression is found in a year, then it will be possible to apply fix for that even if the branch allows only security fixes.+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.
  
-==== Disallowing new features completely in RC and bug fixing release ====+==== Extend Releases Cycle to End of Year ====
  
-Currently there is an exception that states following:  +Right now, PHP comes out of normal or security release 2 or 3 years after the first GA release. 
-Bugfixes only (with 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. +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.
  
-This proposes to drop this completely and disallow any feature addition in RC and bug fixing releases.+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.
  
-==== Allow feature that do not require RFC in beta ==== 
  
-We allow RFC to be implemented during beta so other features should be allowed too.+===== Revised Timeline =====
  
-==== Reduce number of RC to 4 ====+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 release cycle is too long so this reduces number of RC's by 2.+  * 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) ===== ===== Proposed PHP Version(s) =====
-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 already apply on PHP-8.0. It means that PHP-8.0 will get extra year of security fixes. 
  
 +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.
  
-===== Open Issues ===== 
-Make sure there are no open issues when the vote starts! 
- 
-===== 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 vote for each proposed point.+A normal 2/3rd majority vote for each of the proposed changed. 
 + 
 +If any of the proposed changes passes, the [[https://github.com/php/policies/blob/main/release-process.rst|Release Process policy document]] 
 +will be updated with any accepted changes, and currently operating rules. 
 + 
 +Voting runs until **Monday April 29th, at noon UTC**. 
 + 
 +<doodle title="Allow features that do not require an RFC in the beta period" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 + 
 +---- 
 + 
 + 
 +<doodle title="Disallow New Features in Release Candidates and Bug Fix releases" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +---- 
 + 
 + 
 +<doodle title="Reduce number of RCs to Four" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +---- 
 + 
 +<doodle title="Extend Security Support by One Year" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +---- 
 + 
 +<doodle title="Allowing recent regression fixes during security support" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +---- 
 + 
 +<doodle title="Extend Releases Cycle to End of Year" auth="derick" voteType="single" closed="false" closeon="2024-04-29T12:00:00Z"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 + 
 + 
  
 ===== Patches and Tests ===== ===== 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 ===== ===== References =====
  
-https://wiki.php.net/rfc/releaseprocess+  * 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 ===== ===== 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.1699220667.txt.gz · Last modified: 2023/11/05 21:44 by bukka

Page Tools