> -----Original Message----- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Sunday, July 06, 2014 2:19 AM > To: Zeev Suraski > Cc: PHP > Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP > > > On 6 Jul 2014, at 00:05, Zeev Suraski <z...@zend.com> wrote: > > > I think there's some confusion here. > > > > If the next version of PHP is going to be a major one (which is > > clearly defined in https://wiki.php.net/rfc/releaseprocess), then I > > believe the only two options that were ever raised are PHP 6 and PHP > > 7. If you're aware of other proposals that were made then please > > state them, otherwise, I think it's a very clear decision between 6 > > and 7 - and putting this as a 'yes/no' for 6 gives it undue advantage. > > Well, if we have the current yes/no to PHP 6 vote, then if it passes, we get > PHP 6. If it doesn't pass, we're back where we were before. > > If we go for PHP 6/PHP 7 vote, then the result is unclear. Would one option > be the default? Would it be PHP 7 if it's not PHP 6? Would it be PHP 6 if it's > not PHP 7? In which case, what's the point in a majority? We could hold a > 50%+1 vote, but such a vote would be contentious and would be a popularity > contest, not requiring consensus. If we don't have a default, and either 6 has > to get 2/3 or 7 has to get 2/3, then we should have an Other option, or a > Continue Discussion option, or both. This is all way too complicated for me and > I don't want the vote to be contentious or confusing.
I'll simply repeat what you already quoted: "If the next version of PHP is going to be a major one (which is clearly defined in https://wiki.php.net/rfc/releaseprocess), then I believe the only two options that were ever raised are PHP 6 and PHP 7." Yes, it'll be 7 if it's not 6; It'll be 6 if it's not 7. Nobody proposed a new versioning scheme and the only reason there is a discussion in the first place is because many people, myself included, are proposing that we skip version 6 - for a variety of reasons (the least of which is books on Amazon). The choice should be between them. Between skipping or not skipping. Putting such a biased RFC is lot more contentious as it actively ignores what many people think - not through oversight, but through insistence to avoid putting up the other option there. Ultimately, we need to make a choice between these two options, and the current RFC goes a long way to hide that fact and deny those who believe in the 2nd option to have their opinion count. > Which options? 6 and 7? This isn't a 6 vs 7 RFC. This is a 6 or not RFC. This RFC makes no sense in its current context. Insisting on keeping it a '6 or nothing' ignores the elephant in the room - that there *IS* just one other option and that option is 7 (again, all of that in the fairly safe assumption that the next version will be a major one per the releaseprocess RFC). Do we really want to go down the route of kindergarten and spin up a 'competing' 'PHP 7 or nothing' RFC? > Sure, I can't make a great case against 6, unfortunately. I am willing to accept > suggestions here. A good start would be reviewing the threads that discussed it already. They had plenty of reasons on why 'PHP 6' is a bad idea that had nothing to do with books or Amazon or authors. I mentioned the thread name is 'About PHP6 ...'. > The entire point of this RFC is to get the discussion over with sooner rather > than later, and hopefully come to a decision quickly so we don't need to > discuss it again. > > Also, I disagree that holding a vote to settle the name matter once and for all > is a waste of energy. It should, hopefully, mean less energy wasted than > otherwise in future. I think you're getting into it thinking we can just swiftly decide that it's going to be PHP 6 and be done with it. We can't. Probably same for 7. There'll be a lot of heated debates, and a lot of energy will go into that. I believe that energy will be much better spent in other fronts at this point in time. But it's even more than that. Your insistence to stick to a '6 or nothing' approach has a fair chance of getting us into a situation where we agree to disagree so that we can all revisit this hot potato sometime later in the future, and waste yet some more energy about it. Quoting your initial email: "Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point." This is the exactly opposite of 'once and for all', and means that this energy could end up being completely wasted. If you *truly* want to settle this once and for all, it needs to have two definite options and not one definite and one open ended option. The way I see it, the available courses of action rated according to my subjective preference: 1. Shelf this until a later time when we actually have a better idea about what php.next is and have spent some more time actually creating it (seriously considering putting up an RFC for that ;) 2. Stick with it, but change the RFC to reflect both camps' opinions and make it definite, so that we don't need to revisit this again in the future 3. Stick with the (IMHO very weird) "PHP 6 or nothing" RFC, and perhaps spin up another "PHP 7 or nothing" RFC. That last option is pretty ridiculous IMHO. What happens if neither option gets 2/3? Or maybe both? There's just no way to choose between two options in the table while pretending one of them doesn't exist. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
