- Name:
refinement_rfc_guidelines - Date: TBD
- Author: Marco Deleu deleugyn@gmail.com
- Proposed Version: PHP 8.2
Since the Release Process RFC from 11 years ago, PHP has greatly matured and evolved on all fronts. The predictable and consistent release cycle and the RFC system has proved to be one of PHP's greatest asset. This RFC proposes to polish once again the existing process to include some rules and guidelines for the Feature Freeze period so that future releases may have a mechanism in place for improvement of features soon to-be released.
This RFC proposes guidelines for a Refinement RFC and uses the following terminology:
| Term | Description |
|---|---|
| Regular RFC | An RFC proposing changes to the language. |
| Refinement RFC | An RFC proposing changes, amendments, adjustments to the language while refining an unreleased change that has been approved. |
| Next Major Release | The current feature freeze branch or the current main branch if feature freeze has not passed yet. |
| Future Major Release | The future main branch or the current main branch if feature freeze has already passed. |
Explicit guidelines are particularly helpful for newcomers. They attempt to make clear what are the possible outcome when proposing changes to the PHP Project. But even veterans may feel more comfortable navigating due process when they are protected by established guidelines.
This RFC has 3 main motivation targeting the parties involved in an RFC: Release Managers, RFC Authors and Voters.
RFC Authors will be protected by the due process when proposing changes even if they have missed the regular deadline. This can be particularly useful if an RFC is approved right before feature freeze but new challenges are uncovered when trying to finalize it's implementation. Refinement RFCs would be a tool to build upon a subject that has been discussed and has been approved, but may require adjustments to better serve the PHP Project.
Release Managers will be granted explicit power that it is their judgement call that decides whether a Refinement RFC can be proposed or not and how it would potentially affect the release timeline. It will also be clear for a Refinement RFC Author that their grant is subject to change if the Release Managers desire.
Voters will be explicitly informed that a Refinement RFC is being proposed and due to it's time sensitivity nature it may take a shorter time than regular RFCs. Their vote will decide whether such a speedy refinement is necessary or not.
- A Refinement RFC MUST be connected to changes made in a Regular RFC that has been accepted but has not been released.
- A Refinement RFC MUST target the immediate next major release.
- A Refinement RFC SHOULD NOT have multiple votes targeting multiple versions.
- A Refinement RFC MAY be proposed with a schedule for ending it's vote after feature freeze if at least one Release Manager approves it.
- A Refinement RFC MUST mention who approved it.
- A Refinement RFC SHOULD avoid syntax changes, if possible.
- A Refinement RFC MAY have a shorter discussion period, respecting a minimum of 10 days, when it's voting ends after feature freeze.
- A Refinement RFC MAY have a shorter voting period, respecting a minimum of 10 days, when it's voting ends after feature freeze.
- A rejected Refinement RFC MUST NOT be subjected to substantial changes or 6 months time for ressurections when targeting future major releases.
- A Refinement RFC MUST NOT end it's voting period after RC1.
- Release Managers MAY delay RC1 for XX days at their own discretion.
- The Release Managers MAY, unanimously, recind the approval for a Refinement RFC at any moment in light of new discovery.
- A Refinement RFC vote is considered void if the Release Managers recind their approval.
This section should provide further clarification on specific topics of the proposal.
- Item 1) establishes that there is no reason to proposal a Refinement RFC if there is no pressing issue with an unreleased feature.
- Item 2) establishes that if an RFC is targeting a Future Major Release, then it doesn't need to borrow any special conditions granted for Refinement RFCs.
- Item 3) establishes that it is preferred that a secondary vote for a Future Major Release could use the abundant extra time unless there's no reason to make use of the extra time.
- Item 4) establishes that under pressing time one release manager grant should be enough to kick-start the process specially in situations that other release managers may be unavailable for a few days.
- Item 6) recommends avoiding syntax changes as those are often controversial and delicate changes to the language. But since Attributes and Nullable Intersection Types did touch on syntax, we should not prohibit it.
- Item 7) and Item 8) gives Release Managers and RFC authors more time by speeding up the process.
Not Applicable
8.2
The whole document pass/fail. Controversial guidelines may have a separate dedicated vote.