Hi
Am 2024-09-26 15:19, schrieb Christoph M. Becker:
While I agree with Bob that by disallowing the RFC implementation
during
the Betas would make Betas and RCs effectively identical. Nevertheless
I
would like to see RFCs with a large impact voted on (and implemented)
*well before* the feature freeze, as the recent history required
following up with another RFC multiple times (e.g. Random Extension in
8.2, BCMath objects in 8.4, Property Hooks in 8.4). Asymmetric
visibility being voted on shortly before the freeze made me a little
uneasy for that reason.
I'm not suggesting to forbid new features during beta, but only to
forbid implementing RFCs during this time. While the implementation of
I'm not sure if that would actually improve anything. It would just move
the effective feature freeze around.
If the implementation of the RFC contains a regular bug there is plenty
of time in the RC period to fix the bug. If the RFC contains a design
issue that only becomes apparent after the implementation has been
merged, then even if the implementation has been merged before the
feature freeze it would be too late to follow-up with another RFC. For
high-profile RFCs it probably would also be too late to revert the
implementation back out, given that would technically also be a change
in features. Also folks generally expect an RFC to ship with the next
PHP version and often already prepare articles well before the PHP
version actually ships. I don't think it would have gone well with the
community if PHP 8.4 didn't actually include property hooks, because of
some unforeseen issue.
And yes, I fully agree about aviz having been very late.
So my conclusion, the only workable solution that I see is a gentleman's
agreement for high-profile / high-impact RFCs [1] to either
- vote and merge them well in advance of feature freeze (no later than
April or so)
- or to intentionally delay it until the first RC release of the current
cycle and then vote it for the next PHP version.
Best regards
Tim Düsterhus
[1] Rule of thumb probably would be everything with new syntax and
everything with non-trivial engine changes.
