On Wed, Aug 24, 2022 at 4:45 AM Alexandru Pătrănescu <dreal...@gmail.com> wrote: > Maybe this should be clarified as the term "small self contained feature" > is not clear. > I mean, a lot of the new features are self contained, depending on how you > view it, and some of them are also small. > Like array_is_list could have gone into PHP 8.0.2 or 8.0.3 release and not > wait for PHP 8.1.0 release? > (Vote ended on 2021-01-20 and was merged on 2021-01-21) > > Just want to make it clear for me how the rules are understanded by > internal devs so I know better. > If it's not an agreement, how can we clarify them better? >
The rules* are pretty clear. Feature freeze means feature freeze. If there's a feature you want in, big or small, you get it approved by the RFC process prior to the feature freeze date for the branch you want it on. Period. * Any good rule is more of a guideline. Specific features or changes to features CAN be considered on a case-by-case basis after the FF date. However, the bar is set high for these exceptions. As an example, in the 8.0 release process, attributes went through a number of syntax changes well into the beta and RC phases. This was NOT ideal, and it was kind of a mess, but it met RM criteria for consideration because it was an already approved and merged new feature, and the consequence of not considering changes to the syntax would mean that we might need to live with a hastily chosen one forever. Essentially, the pressure to consider it came from the potential negative impact. By comparison, the consequence of waiting for the next branch on something like array_is_list() is just a little extra time. That may be disappointing for those wanting the feature, but that disappointment will pass once the next branch is released, and we'll forget the delay ever happened and move on. To generalize: Completely new features are unlikely to gain a feature freeze exception, because they've waited 25 years, so they can wait 26. Tweaks to already approved, but unreleased new features are likely to gain an exception because the impact to the future is already there, we want that impact to be positive. BC breaking fixes for existing functionality (see recent ksort() thread) are probably 50/50 depending on the fix, but as you'll see in that thread, we reverted the "fix" on the 8.0 branch already (fix never saw a release). -Sara
