> On 3 Jul 2020, at 13:27, Nikita Popov <nikita....@gmail.com> wrote: > > Now, whether this RFC actually makes a sufficient case to disregard policy > here is a different question, and at the discretion of the voters.
I think this is key here (the first part, not the second). It doesn’t seem as if the RFC makes any case at all why it urgent to enforce this compatibility break outside of the standard policy. In fact, unless I’m missing something, it doesn’t attempt to tackle that question at all, and portrays it as a simple choice between two equal options that are up to personal preference. That is not the case - our standard policy is an outward facing contract, which we should be very wary of breaking - and at the very least do while taking a very informed, measured decision. We can not assume that all voters fully understand the implications of breaking the policy, or even that this would be breaking policy at all, given that it’s not even mentioned in the RFC. As such, I do think the current state of the RFC is somewhat problematic, and to actually consider introducing it into 8.1, the RFC requires 3 amendments: 1. State that per policy, if the RFC is passed - it would generally go into PHP 9.0. 2. Make the case of why the RFC author believes it’s important to do it in 8.1 and not wait for 9.0 per our public-facing policy. 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite our compatibility policy”, and turn it into a clear Yes/No question that clearly requires a 2/3 majority. Since technically it might be an issue, perhaps we can stick with the current wording, but still make it clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. I think those are fairly minor amendments that can be done without restarting the vote, given where it’s at. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
