# [RFC] Name of Next Release of PHP - Thread: https://externals.io/message/75262 - Original archive: https://news-web.php.net/php.internals/75262 - Started by Andrea Faulds on 2014-07-05T21:23:50+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/75262.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #75262 — Andrea Faulds — 2014-07-05T21:23:50+00:00 URL: https://externals.io/message/75262#75262 Good evening, I am announcing a rather unorthodox RFC. With the advent of the phpng and uniform variable syntax RFCs, it looks likely the next major release of PHP, to succeed the 5.x series, may appear relatively soon. However, unlike with previous releases of PHP, it is not entirely clear what it shall be called. This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment. This is the shortest RFC I’ve ever authored, and I’d greatly appreciate it if everyone read the whole thing: https://wiki.php.net/rfc/php6 The plan for voting, if I think we should go ahead with it, is the same as a normal RFC: at least 2 weeks after proposed to internals, voting for at least 1 week. Thanks! -- Andrea Faulds http://ajf.me/ --- ## #75263 — Zeev Suraski — 2014-07-05T21:57:50+00:00 URL: https://externals.io/message/75262#75263 · In reply to: #75262 Andrea, While I'm not sure whether this isn't a bit premature to have this discussion, if we were to have this discussion, the RFC should do a much better job at summarizing the discussions we already had in the past. First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or Defer Decision' or at least 'PHP 6 / PHP 7'. Secondly, contrary to what the RFC implies, the reasons against using version 6 went far beyond books - and covered much more important things (honestly I never quite understood the preoccupation with this books angle, I don't think anybody at all cares about it). If we decide to do the discussion now, the RFC should cover them (they were discussed in a thread named "About PHP6 ..." Third, numerous people (myself included) actively proposed we skip version 6 and go with version 7; Dismissing that with "I don't think the alternative naming options are really much better" doesn't seem to belong in an RFC. The merits of this option - which were really more about the drawbacks of calling it '6' and the lack of drawbacks of calling it '7' should be properly described in the RFC. Of course, you don't have to buy into that reasoning, but let's not tuck the discussion away under the carpet. If we were to have this discussion now, let's make the best cases we can for both options on the table, instead of focusing on just one and dismissing the opposition as something about books. Another couple of cents - both because of what I said here but also unrelated, I think /rfc/php6 is a bad name for this RFC (both because there's more than one option, but also because this is too generic for something as wide as the next version of PHP). Perhaps /rfc/php2015 is a better choice, or at least /rfc/php.next.name Thanks! :) Zeev > -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Sunday, July 06, 2014 12:24 AM > To: PHP > Subject: [PHP-DEV] [RFC] Name of Next Release of PHP > > Good evening, > > I am announcing a rather unorthodox RFC. > > With the advent of the phpng and uniform variable syntax RFCs, it looks likely > the next major release of PHP, to succeed the 5.x series, may appear > relatively soon. However, unlike with previous releases of PHP, it is not > entirely clear what it shall be called. > > This RFC attempts to settle the matter once and for all with a straight yes/no > vote as to whether the name should be PHP 6. Should it pass, the matter is > settled and we actually have a proper name for this fabled "PHP NEXT". Should > it fail, nothing is really lost, except that the discussion will inevitably resurface > at some point. The plan, really, is to hopefully get it over with now so we don't > have to have this discussion later, avoiding potential future bikeshedding or > derailment. > > This is the shortest RFC I've ever authored, and I'd greatly appreciate it if > everyone read the whole thing: > > https://wiki.php.net/rfc/php6 > > The plan for voting, if I think we should go ahead with it, is the same as a > normal RFC: at least 2 weeks after proposed to internals, voting for at least 1 > week. > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #75265 — Andrea Faulds — 2014-07-05T22:20:25+00:00 URL: https://externals.io/message/75262#75265 · In reply to: #75263 > While I'm not sure whether this isn't a bit premature to have this > discussion, if we were to have this discussion, the RFC should do a much > better job at summarizing the discussions we already had in the past. That’s true. I’ve updated it with more arguments from past discussions. > First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or > Defer Decision' or at least 'PHP 6 / PHP 7’. I don’t want to have a vote with over two choices, I don’t think it would be fair (one option could pass without >50% voting for it), and a binary 6/7 choice is forcing people’s hand. I want it to be simple and straightforward, so that is why it is Yes or No to PHP 6. If people vote no, there could always be a different vote later, but that is not what I want to do. I am not going to change the vote options. > Secondly, contrary to what the RFC implies, the reasons against using > version 6 went far beyond books - and covered much more important things > (honestly I never quite understood the preoccupation with this books > angle, I don't think anybody at all cares about it). If we decide to do > the discussion now, the RFC should cover them (they were discussed in a > thread named "About PHP6 ..." > > Third, numerous people (myself included) actively proposed we skip version > 6 and go with version 7; Dismissing that with "I don't think the > alternative naming options are really much better" doesn't seem to belong > in an RFC. The merits of this option - which were really more about the > drawbacks of calling it '6' and the lack of drawbacks of calling it '7' > should be properly described in the RFC. I’ve covered the PHP 7 issue more now. > Of course, you don't have to buy into that reasoning, but let's not tuck > the discussion away under the carpet. If we were to have this discussion > now, let's make the best cases we can for both options on the table, > instead of focusing on just one and dismissing the opposition as something > about books. Sure. > Another couple of cents - both because of what I said here but also > unrelated, I think /rfc/php6 is a bad name for this RFC (both because > there's more than one option, but also because this is too generic for > something as wide as the next version of PHP). Perhaps /rfc/php2015 is a > better choice, or at least /rfc/php.next.name Right, the URL isn’t entirely ideal, but it’s not really important. I don’t think it’s possible to change it, and this is at least memorable. Really, RFC URLs are pretty meaningless. We’ve had URLs before with spelling errors in them. Thanks. -- Andrea Faulds http://ajf.me/ --- ## #75266 — Zeev Suraski — 2014-07-05T23:05:20+00:00 URL: https://externals.io/message/75262#75266 · In reply to: #75265 > I don't want to have a vote with over two choices, I don't think it would be fair > (one option could pass without >50% voting for it), and a binary 6/7 choice is > forcing people's hand. I want it to be simple and straightforward, so that is why > it is Yes or No to PHP 6. If people vote no, there could always be a different > vote later, but that is not what I want to do. 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. If it's not going to be a major version, then we're talking about PHP 5.7 and there's no reason for this discussion in the first place. Really, the only decision on the table is "what do we call the next version of PHP if it's a major one", and the two options on the table are '6' and '7'. That is, assuming we decide there is a decision to be made on the table to begin with. > I've covered the PHP 7 issue more now. Not really, not in a meaningful way. You haven't covered the real drawbacks of calling it PHP 6 (it's still this books thing which nobody cares about, and perhaps even incites people to support 6 just to spite these 'evil book authors'), and you haven't covered the advantages or disadvantages of calling it 7 - beyond a very weak and very biased dismissal. I'm intentionally not going into those here, because I don't want to (re)start the discussion right here and now. A lot has been said already about this and the RFC should reflect it, or not move ahead. > > […] > > Sure. Andrea - this updated RFC is the very definition of tucking the discussion under the carpet and trying to run ahead to force a 6 decision without doing the discussion that already took place any justice. The only way to really make the case for both options is for someone who believes in each option to make the case; And to make this RFC about a decision between these two. You may be the one for 6 but you're clearly not the one for 7; I could be that someone if this can wait for later in July (and I see no reason why it couldn't). However, I have to say I wish that instead of (IMHO) wasting energy on such a discussion at this point, we'd focus on the actual content of php.next. People sharing phpng benchmarks and testing it with their apps would be a whole lot more productive use of our time. Zeev --- ## #75267 — Andrea Faulds — 2014-07-05T23:18:56+00:00 URL: https://externals.io/message/75262#75267 · In reply to: #75266 > 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. Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where we were before. If it passes, the name is PHP 6. It could not be more straightforward, and the result cannot be misinterpreted. It requires a 2/3 majority to pass, so it would require consensus. Again, this is my position and I am sticking to it. I see no good reason to complicate matters. > > […] > > Not really, not in a meaningful way. You haven't covered the real > drawbacks of calling it PHP 6 (it's still this books thing which nobody > cares about, and perhaps even incites people to support 6 just to spite > these 'evil book authors'), and you haven't covered the advantages or > disadvantages of calling it 7 - beyond a very weak and very biased > dismissal. I'm intentionally not going into those here, because I don't > want to (re)start the discussion right here and now. A lot has been said > already about this and the RFC should reflect it, or not move ahead. I’m willing to take suggestions, if that could improve it. > Andrea - this updated RFC is the very definition of tucking the discussion > under the carpet and trying to run ahead to force a 6 decision without > doing the discussion that already took place any justice. > > The only way to really make the case for both options is for someone who > believes in each option to make the case; And to make this RFC about a > decision between these two. Which options? 6 and 7? This isn’t a 6 vs 7 RFC. This is a 6 or not RFC. Sure, I can’t make a great case against 6, unfortunately. I am willing to accept suggestions here. > However, I have to say I wish that instead of (IMHO) wasting energy on > such a discussion at this point, we'd focus on the actual content of > php.next. People sharing phpng benchmarks and testing it with their apps > would be a whole lot more productive use of our time. 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. -- Andrea Faulds http://ajf.me/ --- ## #75268 — Zeev Suraski — 2014-07-06T00:10:12+00:00 URL: https://externals.io/message/75262#75268 · In reply to: #75267 > -----Original Message----- > From: Andrea Faulds [mailto:ajf@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 > > > > > > […] > > 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 --- ## #75269 — Kris Craig — 2014-07-06T00:23:11+00:00 URL: https://externals.io/message/75262#75269 · In reply to: #75267 > > > > > […] > otherwise, > > […] > a > > […] > > 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. > > Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where we > were before. If it passes, the name is PHP 6. It could not be more > straightforward, and the result cannot be misinterpreted. It requires a 2/3 > majority to pass, so it would require consensus. Again, this is my position > and I am sticking to it. I see no good reason to complicate matters. > I tend to agree. PHP 6 is the next increment. The question is whether we should continue following that standard or break from it for the reasons raised in the previous thread. If we break from it, then we'd have to decide what the next version name would be. However, based on the results of the previous thread on this matter, it seems extremely unlikely that the vote wouldn't be yes for PHP 6, so I don't think there's any pressing need to expand the scope of this vote beyond that. We should first establish whether or not we're sticking with the current conventions and going with PHP 6. If the vote is in favor of going another route, we can then put together a new RFC to figure out what the new convention should be (whether to arbitrarily skip a version increment or do away with the incremental number entirely and go with something else, like "PHP " or "PHP "). I certainly wouldn't agree that 7 is the only other option. Personally, my vote would be to keep the current naming convention and not skip 6. But if the outcome goes the other way, my preference would be to break from the incremental number system altogether because that'd be less confusing than an arbitrary skip, so it'd make more sense to be able to vote on that when and if people vote to discontinue the current naming convention and not go with the next increment of 6. --Kris --- ## #75270 — Kris Craig — 2014-07-06T00:29:08+00:00 URL: https://externals.io/message/75262#75270 · In reply to: #75269 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 --- ## #75271 — Andrea Faulds — 2014-07-06T00:42:34+00:00 URL: https://externals.io/message/75262#75271 · In reply to: #75270 > 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. Right. As I said, I’m willing to improve the Rationale section with suggestions, I just can’t think of many other arguments for at the moment. Perhaps I need to delve deeper and read some more previous discussions. I’m not in favour of the version skip, and though I can play devil’s advocate, I am not really very good at doing so here. I don’t dispute that the Rationale section could do with improvement. > > 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. I’m not exactly sure what you’re talking about here, but to clarify: It is a 2/3 majority-required vote on whether or not the name should be PHP 6. That would be in line with the current convention of incrementing the major version number. I can see Zeev’s point that 7 is the main other option (though I also think 6.1, or codenames, are possible though unlikely other options). However, I don’t want to call a 50%+1 6/7 vote because it just feels like too narrow of a majority. I suppose if that 6 yes/no vote fails, I might consider a 50%+1 6/7 vote. Bear in mind I proposed at some point recently that we use 2/3 for all votes. That was largely related to the 64bit RFC, but I still agree with the principle. To be honest, I may end up retreating at this point and just calling a 50%+1 before even running a 2/3 one. My problem with that is that I feel such a narrow majority would be too contentious and not end the discussion for good. Sadly, it is not realistic to hold a vote on the majority with which to vote. ;) -- Andrea Faulds http://ajf.me/ --- ## #75273 — Andrea Faulds — 2014-07-06T01:09:46+00:00 URL: https://externals.io/message/75262#75273 > Andrea Faulds wrote: > > > […] > > Have you considered a 6 vs. 7 vs. other vote, which would require a > majority (i.e. > 50%) to pass? In my first reply to Zeev, I said I was opposed to having a 6/7/other vote with a plurality, but a 50%+1 vote of that kind might be more tolerable. Then again, the “other” votes might ensure nothing passes. To be honest, I’d much rather just do a 6/7 50%+1 vote in that case. I suppose I could also do a 6/7 2/3 majority vote in place of the 6 yes/no 2/3 majority vote the RFC proposes, though then again, you’d have the question of what to do if neither gets an outright majority. Of course we have that problem anyway with a yes/no 2/3 majority vote. Argh, I need some sleep. I’ll think about it further and respond in the morning. -- Andrea Faulds http://ajf.me/ --- ## #75274 — Zeev Suraski — 2014-07-06T01:13:51+00:00 URL: https://externals.io/message/75262#75274 · In reply to: #75270 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.craig@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 --- ## #75275 — Zeev Suraski — 2014-07-06T01:14:51+00:00 URL: https://externals.io/message/75262#75275 · In reply to: #75273 > Argh, I need some sleep. I'll think about it further and respond in the morning. I think we have consensus here! Zeev --- ## #75276 — Zeev Suraski — 2014-07-06T01:15:32+00:00 URL: https://externals.io/message/75262#75276 > -----Original Message----- > From: Zeev Suraski [mailto:zeev@zend.com] > Sent: Sunday, July 06, 2014 4:15 AM > To: 'Andrea Faulds'; 'Christoph Becker' > Cc: 'Kris Craig'; 'PHP' > Subject: RE: [PHP-DEV] [RFC] Name of Next Release of PHP > > > […] the > morning. > > I think we have consensus here! Err, sorry for bugging everyone with yet another email but just to make sure I'm not misinterpreted - I meant that *I* also need to get some sleep, not that I agree you should :) Zeev --- ## #75277 — Kris Craig — 2014-07-06T02:07:22+00:00 URL: https://externals.io/message/75262#75277 · In reply to: #75271 > > > > > […] > 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. > > Right. As I said, I’m willing to improve the Rationale section with > suggestions, I just can’t think of many other arguments for at the moment. > Perhaps I need to delve deeper and read some more previous discussions. I’m > not in favour of the version skip, and though I can play devil’s advocate, > I am not really very good at doing so here. I don’t dispute that the > Rationale section could do with improvement. > > > […] > 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. > > I’m not exactly sure what you’re talking about here, but to clarify: It is > a 2/3 majority-required vote on whether or not the name should be PHP 6. > That would be in line with the current convention of incrementing the major > version number. > > That's exactly my point; i.e. "2/3.... whether or not" seems ambiguous to me. Does that mean that a 2/3 "yes" vote is required for the version to be PHP 6? Or does it mean that a 2/3 "no" vote is required for the version *not* to be PHP 6? --Kris --- ## #75278 — Lester Caine — 2014-07-06T08:21:27+00:00 URL: https://externals.io/message/75262#75278 · In reply to: #75274 > 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. The problem with that statement is just how do you identify what material one is looking at relates to the 'current' PHPNext? My only argument for not using 'PHP6' is simply that there is a substantial volume of material, printed and otherwise, related to all the discussions on PHP6. We now have discussion on phpng which ring fences that particular development fork, and phpnext is also being used, but using that then creates a problem with next+1. As with windows development with branches like NT and Vista, strict adherence to a number sequence is not essential, but we need some cleanly identifiable tag for the current 'next' discussions simply to remove the dross? *IS* phpng a fore gone conclusion as the base of phpnext? So has this debate already been decided and are we now working on phpng only anyway? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #75281 — Andrea Faulds — 2014-07-06T11:21:29+00:00 URL: https://externals.io/message/75262#75281 · In reply to: #75262 > This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment. The RFC has been updated. I’ve backed down and made the vote be 50%+1 with the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win. Hopefully this should be decisive, unless the number of Yes and No votes matches. -- Andrea Faulds http://ajf.me/ --- ## #75283 — Andrea Faulds — 2014-07-06T15:08:02+00:00 URL: https://externals.io/message/75262#75283 > Andrea - Your total disregard for anything other then a a single reason > related to books is a problem here. While printed /electronic books are > a part of the problem with the tag PHP6, there are considerable > additional references to that tag over the last 10+ years, along with a > substantial amount of code in the code base which was a dead end. PHP6 > has been linked with development work which will not now be taken forward. I don’t have a total disregard for it. I acknowledge the argument that PHP 6 was a real thing, although it never was released properly and was eventually abandoned. If the RFC isn’t clear enough about this argument, again, I welcome suggestions to improve it. I’d suggest talking with me on IRC about it (#php.pecl on EFNet) if you catch me there, might mean less noise than here on the list. Of course, nothing wrong with email. > To some extent WHAT the next version is released as is perhaps not the > problem here, but rather being able to simply identify third party > discussions relating to the current roadmap(s) for PHPNext? It's just > the matter of ring fencing what is the current roadmap and plan for > PHPNext and isolating that from the older existing PHP6 documented plans > ... The use of PHP7 can be simply explained, fits in perfectly with the > code base, and provides a clean tag to move forward? Using some > alternative tag until a release is ready and then switching back to PHP6 > simply does not make sense? We have no PHP-6 or PHP-6.0 tag/branch in git, I see no reason why we wouldn’t call it PHP 6 before release, if we decide to call it PHP 6, of course. I think it’s generally clear what’s for the new PHP 6 and what’s for the old; anything from after the old PHP 6 was abandoned must be about a new PHP 6, and anything from before it must be about the old PHP 6. If this RFC were to pass with people voting for 6, then it would be pretty clear that anything coming after it was about the new PHP 6. -- Andrea Faulds http://ajf.me/ --- ## #75284 — Jocelyn Fournier — 2014-07-06T15:12:31+00:00 URL: https://externals.io/message/75262#75284 · In reply to: #75274 Hi, Le 06/07/2014 03:13, Zeev Suraski a écrit : > 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. > It's my first post in this list, and wanted to share my external point of view, with a parallel with the MySQL world. MySQL 6 was alpha in 2007 and finally was never released. So far its name has never been reused (instead we had MySQL 5.6 and 5.7 to avoid confusion, and there are also books about PHP 6 / MySQL 6) Even on the MariaDB side, they bumped up the version to 10.0 to avoid confusion (and because it was not based on MySQL 5.6). There are quite a few tutorials and reference about PHP 6 on the web, it would be misleading to have something completely different, but with the same name as the "old" PHP 6. However I'm not convinced "7" is the right choice, perhaps a radical change in version number would be better ? -- Jocelyn Fournier --- ## #75285 — Andrea Faulds — 2014-07-06T15:19:29+00:00 URL: https://externals.io/message/75262#75285 · In reply to: #75284 > It's my first post in this list, and wanted to share my external point of view, with a parallel with the MySQL world. Welcome to PHP! :) > MySQL 6 was alpha in 2007 and finally was never released. > So far its name has never been reused (instead we had MySQL 5.6 and 5.7 to avoid confusion, and there are also books about PHP 6 / MySQL 6) > Even on the MariaDB side, they bumped up the version to 10.0 to avoid confusion (and because it was not based on MySQL 5.6). Similarly, ECMAScript 4, which was to be the replacement for ECMAScript 3, was abandoned and skipped, with ECMAScript 5 replacing it and ECMAScript 6/Harmony continuing it in spirit. There is some precedent for this. > There are quite a few tutorials and reference about PHP 6 on the web, it would be misleading to have something completely different, but with the same name as the "old" PHP 6. However I'm not convinced "7" is the right choice, perhaps a radical change in version number would be better ? Well, 7 is a nice number. But yes, a more radical change might be better. How about PHP 14, after the year? PHP Loxodonta, a genus of elephants? PHP 14.mm, where mm is the month, following the Ubuntu month/year scheme? However, all other options only seem to have fringe support at the moment, so a binary 6/7 vote is optimal, unless you can find a name everyone can agree on. Keeping with 6 or 7 means we stick to our tried and tested naming scheme, too. I think that’d be for the best. Side note: another thought comes to me now that just skipping 6 and going to 7 makes little sense in a way, as 7 isn’t the successor to 6, it is the second successor to 5, the first (the old PHP 6) having been abandoned. -- Andrea Faulds http://ajf.me/ --- ## #75287 — Andrea Faulds — 2014-07-06T17:06:54+00:00 URL: https://externals.io/message/75262#75287 > > > […] > > https://www.google.co.uk/search?q=php6+site%3Abugs.php.net ... > > Now one can filter additional on date, but the point here is that just > starting with the bugs list we have conflicting material that needs to > be avoided. PHP6 WAS documented extensively even just on the web site, a > lot of that material gets mirrored with more recent timestamps which > makes filtering what is new and what is old a lot more difficult. Even > PHP7 appears quite often on the website, but fortunately not too often > in the bugs list … Can’t we just rename the PHP 6 category to “Old PHP 6” on bugs.php.net and be done with it? Or does it not work like that? -- Andrea Faulds http://ajf.me/ --- ## #75288 — Zeev Suraski — 2014-07-06T17:35:50+00:00 URL: https://externals.io/message/75262#75288 · In reply to: #75287 When you have infinity at your disposal, skipping 6 and taking the next free number - 7 - makes a whole lot more sense than trying to rewrite the archives of history (renaming 6 to Old 6). Similarly, while there are fairly good reasons on why we shouldn't use 6, there aren't any for the next-in-line number - 7 - so the whole question on maybe we should pick 14, Luxonda or anything else that implies we change our versioning scheme. We're not - we're just not using a version number that was already used. Zeev > > > > > […] > > Can’t we just rename the PHP 6 category to “Old PHP 6” on bugs.php.net and be done with it? Or does it not work like that? > -- > Andrea Faulds > http://ajf.me/ --- ## #75289 — Zeev Suraski — 2014-07-06T17:37:51+00:00 URL: https://externals.io/message/75262#75289 · In reply to: #75281 > > > > > […] > > The RFC has been updated. I’ve backed down and made the vote be 50%+1 with the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win. > I appreciate your change! As such I'd like to coauthor it with you and represent the case for 7. Zeev --- ## #75290 — Andrea Faulds — 2014-07-06T19:03:36+00:00 URL: https://externals.io/message/75262#75290 · In reply to: #75289 > I appreciate your change! > > As such I'd like to coauthor it with you and represent the case for 7. You’re welcome to edit the RFC and add a subsection with a case for 7. I’d appreciate it if you could discuss edits to the existing Rationale with me (I don’t want it to unintentionally be too 7-sided). If you can catch me on IRC, that would be optimal. -- Andrea Faulds http://ajf.me/ --- ## #75291 — Sara Golemon — 2014-07-06T20:03:13+00:00 URL: https://externals.io/message/75262#75291 · In reply to: #75290 For my $0.02, as someone who put a fair amount of effort into PHP6 (function conversions, streams layer, etc...) I would really prefer to not call it PHP6. Whether not not it was ever released, it was a thing, and phpng (while awesome) is not that thing. PHP7 seems the obvious choice, but I'm not that bothered if we call it something else. Just please not 6. -Sara --- ## #75292 — Kris Craig — 2014-07-06T22:32:53+00:00 URL: https://externals.io/message/75262#75292 · In reply to: #75289 > > As such I'd like to coauthor it with you and represent the case for 7. > Andrea, I would *strongly* recommend that you accept Zeev's offer and make him a co-author. You did present at least a partial argument for breaking the convention, but I think they do have a valid grievance in that some of their arguments are being left-out. This is understandable, as you have a bias in favor of preserving the order and keeping it at PHP 6. I actually agree with you 100% on this-- but that just means that I'm biased, too. It seems only fair that someone biased on the other side should be allowed to present his arguments and I'm sure he can be trusted to keep his edits to that one section. Likewise, you can then focus on expanding the arguments for preserving the convention if you think that's necessary. And thanks for updating the required majority. "2/3 either way" just seemed too ambiguous and confusing. In the unlikely event of an exact tie, I think we'd just regard the RFC as moot and proceed as if this RFC had never been presented. I'll certainly be arguing strongly in favor of PHP 6 being the next version as I have in the past, but in the interest of fairness, Zeev should be made a co-author and given the mandate to write a section representing the arguments against PHP 6. That way, if the vote goes for PHP 6 and people want to say it's because the arguments against in the RFC weren't good enough, that'll be on him instead of you. --Kris --- Next page: https://externals.io/message/75262.md?page=2