I want to point out that neither options (6 nor 7) break the our convention. PHP 6 was a live project that was worked on by many people, and known as such by many many more; Even though it never reached GA – there was definitely software named PHP 6. Whether reusing that version number for something completely different several years later constitutes breaking the current convention or applying it to reality it is open for interpretation. I also suggest we don’t go in the direction of the 2/3 interpretation – as I pointed out in the past this places undue power in the hands of the RFC author and his interpretation of the voting RFC (which absolutely needs to be amended to fix that). That’s yet another reason on why the vote should be between 6 or 7 so that problem goes away completely – it becomes a clear choice that will have result in a clear cut decision.
If we keep it as a ‘PHP 6 or nada’ there’s a fair chance I’ll write an alternative RFC, most probably not a ‘7 or nada’ but the much more fair ‘6 or 7’ RFC. From the beginning, people who believed there was a problem with using PHP 6 said we should skip a version, and not move to 6.1 or change our versioning scheme. It was only those who opposed it (i.e. those who believed we should go with 6) that brought up alternative ideas – but really wanted to stick with 6. Judging from what you said, if you had 3 options, 6, 7 or change_versioning_scheme, you’d pick the first option, not the last. From the discussion we had on internals – nobody’s first choice was that change_versioning_scheme option, it was either 6 or 7, stick or skip. That’s why it makes absolute sense to have these as the two options available for voting. If 7 gets chosen and you end up feeling that it’s so horrendous we need to change our entire versioning scheme, you’d of course have the option of proposing another versioning scheme and convince people to vote for it… But right now, you’re adding options which are both completely outside the realm of our versioning scheme, AND aren’t what you’d vote for anyway – just to avoid having the real other option that’s on the table be a valid choice for voting. I still absolutely think we should bury this until later in the project’s lifecycle as our energy **right now** is probably much better spent elsewhere. Zeev *From:* Kris Craig [mailto:kris.cr...@gmail.com] *Sent:* Sunday, July 06, 2014 3:29 AM *To:* Andrea Faulds *Cc:* Zeev Suraski; PHP *Subject:* Re: [PHP-DEV] [RFC] Name of Next Release of PHP I would, however, recommend that Andrea take Zeev's input and create a more comprehensive section outlining his arguments in favor of breaking from the current convention. Another section could be created to outline the other side. What we don't want is a situation where Zeev feels compelled to write a competing RFC. That could get messy, so I think it'd be best if the two of you could find enough common ground to make this RFC acceptable to both sides. I'd also recommend that, since you're calling for a 2/3 vote, you specify more clearly what it is that requires 2/3; breaking the current convention or keeping the current convention? I'm guessing you probably meant the former, but the wording seemed a bit vague on that point to me. --Kris
