Fix release process feature freeze info

[bukka]

This is currently incorrect as there has been changes to the release process in https://wiki.php.net/rfc/release_cycle_update#allow_features_that_do_not_require_an_rfc_in_the_beta_period so the new policy for beta allows new features: https://github.com/php/policies/blob/06ef24434942f3b09241ccbde124b83ca8a18042/release-process.rst#beta-releases

[TimWolla]

I don't think this is an accurate change. The policies document says:

Beta 1: Tag / Feature Freeze: $rd + 40 (Aug 13, 2024)

and

After feature freeze, with blessing of the release managers:

• Merging features that do require an RFC is still allowed.
• Features that do not require an RFC are still allowed.
• Optimisations and internal ABI and API changes are also still allowed.

Highlighting mine. This means the policies document defines the feature freeze to happen at the time of Beta 1 and define the feature freeze as “Release Managers need to approve changes that are a feature”, which is a reversal of the process before feature freeze where features may be shipped by gentleman's agreement.

[TimWolla]

Specifically this also means that RFCs with a non-trivial implementation should be voted on well before the voting deadline, since release managers have the ultimate decision regarding whether or not the implementation is “too risky” to stabilize during Betas and RCs (possibly taking the greater ecosystem into account).

[bukka]

Beta 1: Tag / Feature Freeze: $rd + 40 (Aug 13, 2024)

Ah I missed this one. I think it was kind of left by accident because we specifically put this to the RFC:

Feature freeze is supposed to happen when we start making beta releases, but this does not always happen.

Think it was driven by RFC so the changes to the policy came later IIRC or it was just missed.

But logically if we allow features it shouldn't be called a feature freeze

which is a reversal of the process before feature freeze where features may be shipped by gentleman's agreement.

Previous official process was not to allow any features except the RFC implemenation features. We just did not follow it and merge some features.

Specifically this also means that RFCs with a non-trivial implementation should be voted on well before the voting deadline, since release managers have the ultimate decision regarding whether or not the implementation is “too risky” to stabilize during Betas and RCs (possibly taking the greater ecosystem into account).

Yeah I think that you are right here. It was actaully not an intention but it ended up like this.

Ok I think I need to reword this and probably still keep the name "feature freeze" even though I don't really like it.

[bukka]

Ok I rewrote it to more reflect the policy. So I kind of split it to soft and hard feature freeze. Let me know if that looks better.

[DanielEScherzer]

the 5 weeks is new, is that intentional?

[TimWolla]

It makes sense to me to have the 5 week reminder, since that gives folks one week to finalize the RFC before needing to start the discussion (= the RFC text will be less rushed).

[bukka]

Yeah that was exactly the point to give time for announcing the RFC that can still make it...

[edorian]

Maybe even 6 weeks would make more sense then, as that can be announced together with the alpha1 tag?

"We're starting the release procedure now. Here is alpha1. Reminder: You have two weeks to get your RFCs ready for voting."

[TimWolla]

Let me know if that looks better.

Yes, this looks much better now. I had one minor wording remark, but other than that it LGTM and seems to match both the policy and the “actual practice”.

[TimWolla]

Not a release manager, but the updates all make sense to me and I don't have any further concerns.

[DanielEScherzer]

I don't think we need RM approval for

• before hard feature freeze
• with a successful RFC

those should be done with the normal review process. https://wiki.php.net/rfc/release_cycle_update doesn't make it clear if

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.

if "as is already the case" is about approving small non-RFC features, or all features

[edorian]

My main struggle with this is that neither the policy doc. nor the RFC clearly defines what a "Feature" is. Even the linked Wikipedia article leaves it open to interpretation.

We propose to explicitly allow minor features, optimizations, and internal API / ABI changes, during the beta period.
This is the closest I could find to a definition.

So, to me, the terms "soft" and "hard" feature freeze don't really change the process - they introduce two more labels with specific meanings, but they are defined in the new text. Which is an improvement. Tim mentioned that Debian uses similar terminology, which I found clear and helpful: https://release.debian.org/testing/freeze_policy.html#soft

That said, this mainly needs to work for php-src contributors. So I defer to your judgment - if requiring explicit RM approval for merging voted RFCs between beta1 and RC1 makes sense, I’m on board. But then shouldn't all bigger refactorings require approval?

[Girgias]

AFAIK the only time an RM has ever used its right to potentially veto a merge was this comment: #7468 (comment) and that was already in RC.

IMHO RMs should not be able to deny merging of PRs and features as @edorian pointed out this could also be extended to major refactorings, which should be allowed.

Moreover, RMs are not expected to have the php-src knowledge to judge the quality of an implementation. And I don't think I have ever seen a RM block a merge.