On Sat, Mar 9, 2024, at 5:07 AM, Jakub Zelenka wrote: > On Fri, Mar 8, 2024 at 6:30 PM Jim Winstead <j...@trainedmonkey.com> wrote: >> On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: >> > On Tue, 5 Mar 2024 at 20:17, Larry Garfield <la...@garfieldtech.com> wrote: >> >> >> >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 >> >> options reaches 66%? >> >> >> >> The viable options here are a single RCV vote (which we've done before), >> >> or a single "Should we do this" vote that requires 66%, followed by a >> >> "when should we do this" vote with 2 options, majority wins. >> >> >> >> --Larry Garfield >> > >> > Does this work for you guys? >> >> This is a lot of votes for a set of pretty simple changes with minimal BC >> implications, and maybe there's precedent for it but I don't like voting >> about what version to make particular changes in. Adding a language feature >> like property hooks is a one-vote RFC but fixing sleep() to take/return >> floats and work consistently cross-platform is somehow a six-vote ballot? Is >> there anyone who has indicated in any way that they would vote against >> making all three changes because one of the three is somehow unacceptable? >> What if #3 fails but not #1? > > I agree that there's a clear dependency on #1 (other way round than the above > actually... :) ). It might make more sense to do #1 as a primary vote and > then the rest as a secondary votes. I think it makes sense to have more votes > in this case as each thing has its own consideration and BC impact which is > primary difference compare to hooks RFC.
Yeah, I got my example a little backwards, but either way is pretty goofy. >> And I'd say leave it up to the release managers to decide what version it is >> appropriate for the PR implementing an approved RFC go into. Micro-managing >> that by voting does not sit well with me. > > RM has no power to decide about features going in before the first beta. You > would need to update the policies to explicitly give RM such power. Voting is > currently the only way we have to decide such thing if there is no clear > agreement which I think wasn't the case in the PR's proposed for this. This may be a dumb question, but what's the process for determining whether the next significant release of PHP will be a minor version or a major version? If the adherence to semantic versioning is meant to be strict, it doesn't make any sense to vote on what version something like belongs to, because then you're saying that whether a BC break is significant enough to merit an increase to the major version is up for vote. I guess what I'm saying is that one way to deal with it if an RFC is a change that breaks backwards compatibility in any way, it can be passed at any time but the change only lands in whatever the next major version may be. So the RFC could have passed for this change to sleep() back before 8.1 was ever released and the change would just be waiting for the next release of a major version, subject to whatever process there is for deciding whether the next significant release is a major or minor version. (The way I think I would prefer is trusting the release managers to judge whether a BC break is significant enough to merit putting a change on ice until the next major version. Doing it by vote feels like excessive micro-management by voting, and doing it three times in one RFC for the sleep() function is bonkers.) Jim
