I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.
Furthermore, we are past the RFC stage. We are supposed to already
have an alpha by now and we are proposing new changes?. Please stick
to our established rules and release timetables as much as possible,
thank you.
I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.Furthermore, we are past the RFC stage. We are supposed to already
have an alpha by now and we are proposing new changes?. Please stick
to our established rules and release timetables as much as possible,
thank you.
On a related note it is unclear what BC breaks are exactly allowed in
minor releases. Adding new reserved types is a BC break, but it was
done in PHP 5.4 with callable. We should solidify what we do and do
not allow in minor releases for the PHP 7 release series.
On a related note it is unclear what BC breaks are exactly allowed in
minor releases. Adding new reserved types is a BC break, but it was
done in PHP 5.4 withcallable. We should solidify what we do and do
not allow in minor releases for the PHP 7 release series.
5.4 is the wrong example to look at for BC precedent. It was immediately after 5.4's large number of changes (which were largely refugees from the sinking of 6.0) that a policy was adopted, and followed for 5.5, 5.6, and 7.0.
It still leaves some room for controversial interpretation, but it certainly disallows many of the things that happened in 5.4 outside of a major release, and this is by design.
https://wiki.php.net/rfc/releaseprocess
Regards,
Rowan Collins
[IMSoP]
I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.Furthermore, we are past the RFC stage. We are supposed to already
have an alpha by now and we are proposing new changes?. Please stick
to our established rules and release timetables as much as possible,
thank you.
To be fair, this change does not change a single byte of code. It's just
adding another type to the "reserved" list (to be documented) in the
manual. Unless I'm mistaken.
If the above really is the case, then why not stick up an RFC and vote.?
P.S. I'm not 100% clear on the outcome of all of these votes on what is
"reserved" and whether any of those give warnings/etc. in PHP 7; maybe
someone could give me an executive summary off-list? :)
I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.Furthermore, we are past the RFC stage. We are supposed to already
have an alpha by now and we are proposing new changes?. Please stick
to our established rules and release timetables as much as possible,
thank you.
While I agree that we should be wary of anything which break process,
I think we should give some thought (possibly an RFC thought) to
whether or not Documentation-only changes, such as what Nikita
suggested, are actual violations of a feature freeze.
Could one put up an RFC for "void" reservation right up to the release
date of 7.0.0-final? I would say "yes". Such an RFC is
documentation-only and has no code behind it. Therefore it would have
no impact on alpha/beta/rc testing. It's really a langspec RFC more
than a runtime RFC to be quite honest.
-Sara