I want to suggest that we do not allow any RFC implementations to land
during beta phase. In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.
For instance, the implementation of "Deprecate proprietary CSV escaping
mechanism"[1] landed just prior to 8.4.0beta1[2]. However, a serious
issue with that implementation had only be fixed about two weeks ago[3],
and the discussion what to do about that[4] is still unresolved.
So in this case, the implementation would have been right in time, but
still somewhat late.
An even more problematic example would be the "Support object type in
BCMath" RFC[5]. This has only been implemented shortly prior to
8.4.0beta5[6], so there has been almost no time to address overlooked
issues prior to 8.4.0RC1. A pretty serious bug in the implementation[7]
has just been fixed[8] without any real chance to discuss the actual
fix. I'm not arguing that the fix should be reverted, but I'm rather
pointing out that late RFC implementations could easily lead to those
issues over and over again.
I want to suggest that we do not allow any RFC implementations to land
during beta phase. In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.
For instance, the implementation of "Deprecate proprietary CSV escaping
mechanism"[1] landed just prior to 8.4.0beta1[2]. However, a serious
issue with that implementation had only be fixed about two weeks ago[3],
and the discussion what to do about that[4] is still unresolved.
So in this case, the implementation would have been right in time, but
still somewhat late.
An even more problematic example would be the "Support object type in
BCMath" RFC[5]. This has only been implemented shortly prior to
8.4.0beta5[6], so there has been almost no time to address overlooked
issues prior to 8.4.0RC1. A pretty serious bug in the implementation[7]
has just been fixed[8] without any real chance to discuss the actual
fix. I'm not arguing that the fix should be reverted, but I'm rather
pointing out that late RFC implementations could easily lead to those
issues over and over again.
I certainly can see where you are coming from. But that's mostly what is defining the beta phase - an evolving version of PHP, but where it's clear which features will make it (i.e. all RFCs have to be accepted by then) - a period where people can start introducing support for the next PHP version without being surprised at yet unknown breaks.
The period of stabilization of the new features is the RC phase. If you feel we don't have enough time to stabilize, I'd rather enlarge the RC phase (possibly at the expense of 1-2 betas).
I consider it important to retain the policy of submitting RFC implementations during beta, so that implementations are not rushed and thoroughly reviewed before being merged. The cutoff for RFCs being accepted is the first beta, but a lot of RFC implementations don't quite yet have the desired quality for merging. It's important to allow implementations to mature before merging.
I want to suggest that we do not allow any RFC implementations to land
during beta phase. In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.
FWIW, there was a recent RFC to clarify what is acceptable in which phase of the release process. Given that you did not vote there, I believe you might have missed it: PHP: rfc:release_cycle_update
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.
Hi all,
I want to suggest that we do not allow any RFC implementations to land
during beta phase. In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.
For instance, the implementation of "Deprecate proprietary CSV escaping
mechanism"[1] landed just prior to 8.4.0beta1[2]. However, a serious
issue with that implementation had only be fixed about two weeks ago[3],
and the discussion what to do about that[4] is still unresolved.
So in this case, the implementation would have been right in time, but
still somewhat late.
An even more problematic example would be the "Support object type in
BCMath" RFC[5]. This has only been implemented shortly prior to
8.4.0beta5[6], so there has been almost no time to address overlooked
issues prior to 8.4.0RC1. A pretty serious bug in the implementation[7]
has just been fixed[8] without any real chance to discuss the actual
fix. I'm not arguing that the fix should be reverted, but I'm rather
pointing out that late RFC implementations could easily lead to those
issues over and over again.
Thoughts?
[1]
[<https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism>](https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism)
[2]
[<https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e>](https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e)
[3]
[<https://github.com/php/php-src/commit/f756b96e06db29a978bbf3ad3a5c52f6d0d97c64>](https://github.com/php/php-src/commit/f756b96e06db29a978bbf3ad3a5c52f6d0d97c64)
[4] [<https://github.com/php/php-src/pull/15569#issuecomment-2354447087>](https://github.com/php/php-src/pull/15569#issuecomment-2354447087)ff
[5] [<https://wiki.php.net/rfc/support_object_type_in_bcmath>](https://wiki.php.net/rfc/support_object_type_in_bcmath)
[6]
[<https://github.com/php/php-src/commit/fad899e5662d0a929d8462dd8239b0489dd9b53f>](https://github.com/php/php-src/commit/fad899e5662d0a929d8462dd8239b0489dd9b53f)
[7] [<https://github.com/php/php-src/issues/15968>](https://github.com/php/php-src/issues/15968)
[8] [<https://github.com/php/php-src/pull/16021>](https://github.com/php/php-src/pull/16021)
Christoph
Hey Christoph,
I certainly can see where you are coming from. But that’s mostly what is defining the beta phase - an evolving version of PHP, but where it’s clear which features will make it (i.e. all RFCs have to be accepted by then) - a period where people can start introducing support for the next PHP version without being surprised at yet unknown breaks.
I would actually like to see it more like the beta should be a version where all big features are implemented and just minor features and potentially ABI breaking fixes or some not too big refactoring is added. RC should be really a stable version that can be tested and only bugs are fixed in it.
I consider it important to retain the policy of submitting RFC implementations during beta, so that implementations are not rushed and thoroughly reviewed before being merged. The cutoff for RFCs being accepted is the first beta, but a lot of RFC implementations don’t quite yet have the desired quality for merging. It’s important to allow implementations to mature before merging.
I would maybe suggest that we actually do cut off for RFC with the first alpha which would give alpha stage to implement it all and beta could used for potentially breaking fixes.
During beta I would keep the rule that any features should be approved by RM but maybe add to it that it should be RM or CodeOwner / Maintainer (like one approval from any of those required) so there is some technical input as well in weighting those changes and it doesn’t get blocked if RM’s are busy. It’s really just to catch some big refactoring or some risky changes.
I want to suggest that we do not allow any RFC implementations to land
during beta phase. In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.
FWIW, there was a recent RFC to clarify what is acceptable in which
phase of the release process. Given that you did not vote there, I
believe you might have missed it: PHP: rfc:release_cycle_update
I missed it while it was under discussion and in voting, but have read
it since then. And I almost fully agree to that RFC, except for the
issue at hand.
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
some RFCs would not be a big deal, we have to draw the line somewhere,
and I like to avoid additional discussions about which RFCs have a
"large impact", and which do not. But I don't necessarily want to be
too strict about that; for instance, PR #13578 has only been merged
after the first beta, although it was there for almost half a year, but
resolving the Windows test failures had not been done timely. So yeah,
some exceptions to the suggested rule would be fine for me.
See also Jakub's mail[1] with which I fully agree.
And yes, I fully agree about aviz having been very late.
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.
I agree with the general sentiment that alpha/beta/rc should be followed in their canonical form:
Alpha - API/ABI gets broken, new stuff gets introduced, big implementations happen
Beta - new big additions are not allowed any more and introduced feature stabilisation and bugfixing occurs (this is where you polish implementations) and general feature freeze goes into effect
RC - final testing, bugfixing and eventually release.
But I think the struggle we have with RFC’s coming late and being a time crunch is the timing of the release - November. The big problem is that the vast majority of development and voting and RFC ironing out happens during summer when a lot of people are on vacations, travel and in general are not here. So come September/October - all hell breaks loose. And that happens every single year.
So while clarifying the alpha/beta/rc should be done, I think we should move the general minor/major version releases to sometime in February/March to give solid 6 months to work through things and give people ability to start RFC’s and finish them while they are not under the pressure of summer vacations/travel/etc.
I agree with the general sentiment that alpha/beta/rc should be followed in
their canonical form:
- Alpha - API/ABI gets broken, new stuff gets introduced, big
implementations happen
- Beta - new big additions are not allowed any more and introduced feature
stabilisation and bugfixing occurs (this is where you polish
implementations) and general feature freeze goes into effect
- RC - final testing, bugfixing and eventually release.
Thank you, I like that! Maybe something like this should be added to
our release cycle documentation.
But I think the struggle we have with RFC's coming late and being a time
crunch is the timing of the release - November. The big problem is that the
vast majority of development and voting and RFC ironing out happens during
summer when a lot of people are on vacations, travel and in general are not
here. So come September/October - all hell breaks loose. And that happens
every single year.
Interesting theory! However, I believe the actual problem is that most
of the developers have a long backlog, so everything gets pushed closed
to the respective deadline. And that leads to the stress around this
time we indeed have for years.
Well, you always have a backlog and there is never enough time, and any pre-release time is packed with people trying to finish things.It’s just over the 20 years I have been reading the list and especially since the release RFC has been adopted, starting mid-august to mid-September practically any sizeable RFC had at least a few people come in with “I was away/vacation/travelling/etc” - basically summer activities. This has been a constant and quite a few times some of the most experienced core devs returned like that and found major problems in RFCs that required everyone to scramble and try to solve it (and a few RFCs didn’t make it into release due to that if my memory serves me right).
All I wanna say I have noticed this trend and I think personally that bumping the release by even 1-2 months would make things easier for everyone. We can make the Beta phase start in November, so everyone who wants to get an RFC into release has to be done by then. After that, we start the beta and RC phases and release a few months later.