Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125695
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 27 Sep 2024 13:01:00 +0200
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] No more RFC implementations during beta phase
In-Reply-To: <c3d56dfb-a1cc-4687-862f-b32104919ac4@gmx.de>
References: <16d24095-564a-41f1-bf7f-cee9466f76ea@gmx.de>
 <00895e0eb252394d9d18c2dbaad4dd37@bastelstu.be>
 <c3d56dfb-a1cc-4687-862f-b32104919ac4@gmx.de>
Message-ID: <da914670dc76b82644eb361daa3f3153@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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.