Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Mon, Jul 7, 2014 at 3:13 PM, Zeev Suraski wrote: >> On 7 ביול 2014, at 08:59, Andrea Faulds wrote: >> >> >>> On 7 Jul 2014, at 13:57, Zeev Suraski wrote: >>> >>> I don't think it's a problem, because I don't think we're two years >>> away from releasing a phpng-based version and I don't think it's a >>> moving target at this point. So I agree we need to remove these >>> uncertainties. >>> >>> I'm going to start an RFC-based discussion for moving phpng to master >>> so that the uncertainties around it are removed. >> >> phpng has mostly been just performance so far, right? Could we use this >> opportunity, where it is not yet master, to make some deeper improvements? > > What do you mean by deeper improvements? > phpng is focused on performance. We can have other improvements for > the next version of PHP, of course... I'd like to start a discussion about IO multiplexing on that subject as well. We could improve lots of performance of both the engine and user scripts. I already started a topic about it on internals, and I should write an RFC about it. I'm also worried about the API of future PHP-Next. php-ng or not, I dont care. What I'd like is a clean API, and well documented, so that it is not as hard to get into code as nowadays. Nowadays its just very hard to put one's head into code when not familiar with it. I want for PHP-Next something clean and documented so that it will be even more open to new minds. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Mon, Jul 7, 2014 at 2:57 PM, Zeev Suraski wrote: >> On 7 ביול 2014, at 08:50, Andrea Faulds wrote: >> >> >> The problem is that people who want to add stuff for PHP 6 feel they have to >> add it to phpng, because if phpng is to be PHP 6, then it would need to be >> based off that branch. >> > > I don't think it's a problem, because I don't think we're two years > away from releasing a phpng-based version and I don't think it's a > moving target at this point. Btw, It seems we follow a different branch. Alone today tells me that it is still a moving target. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 7 Jul 2014, at 14:13, Zeev Suraski wrote: >> On 7 ביול 2014, at 08:59, Andrea Faulds wrote: >> >> >>> On 7 Jul 2014, at 13:57, Zeev Suraski wrote: >>> >>> I don't think it's a problem, because I don't think we're two years >>> away from releasing a phpng-based version and I don't think it's a >>> moving target at this point. So I agree we need to remove these >>> uncertainties. >>> >>> I'm going to start an RFC-based discussion for moving phpng to master >>> so that the uncertainties around it are removed. >> >> phpng has mostly been just performance so far, right? Could we use this >> opportunity, where it is not yet master, to make some deeper improvements? > > What do you mean by deeper improvements? > phpng is focused on performance. We can have other improvements for > the next version of PHP, of course… Well, deep changes that break things are difficult to get into master normally. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
> On 7 ביול 2014, at 08:59, Andrea Faulds wrote: > > >> On 7 Jul 2014, at 13:57, Zeev Suraski wrote: >> >> I don't think it's a problem, because I don't think we're two years >> away from releasing a phpng-based version and I don't think it's a >> moving target at this point. So I agree we need to remove these >> uncertainties. >> >> I'm going to start an RFC-based discussion for moving phpng to master >> so that the uncertainties around it are removed. > > phpng has mostly been just performance so far, right? Could we use this > opportunity, where it is not yet master, to make some deeper improvements? What do you mean by deeper improvements? phpng is focused on performance. We can have other improvements for the next version of PHP, of course... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
And here we go. So basically you are saying that once phpng is stabilized, no matter the api/SRC cleanness, we are good for next. This is very bad and I will vote -1 on anything close to this idea. Besides that, the same kind of estimation was done for opcache, which was a much smaller beast. They went bad by 300%, just saying. On Jul 7, 2014 2:57 PM, "Zeev Suraski" wrote: > > On 7 ביול 2014, at 08:50, Andrea Faulds wrote: > > > > > > The problem is that people who want to add stuff for PHP 6 feel they > have to add it to phpng, because if phpng is to be PHP 6, then it would > need to be based off that branch. > > > > I don't think it's a problem, because I don't think we're two years > away from releasing a phpng-based version and I don't think it's a > moving target at this point. So I agree we need to remove these > uncertainties. > > I'm going to start an RFC-based discussion for moving phpng to master > so that the uncertainties around it are removed. > > Zeev >
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 7 Jul 2014, at 13:57, Zeev Suraski wrote: > I don't think it's a problem, because I don't think we're two years > away from releasing a phpng-based version and I don't think it's a > moving target at this point. So I agree we need to remove these > uncertainties. > > I'm going to start an RFC-based discussion for moving phpng to master > so that the uncertainties around it are removed. phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
> On 7 ביול 2014, at 08:50, Andrea Faulds wrote: > > > The problem is that people who want to add stuff for PHP 6 feel they have to > add it to phpng, because if phpng is to be PHP 6, then it would need to be > based off that branch. > I don't think it's a problem, because I don't think we're two years away from releasing a phpng-based version and I don't think it's a moving target at this point. So I agree we need to remove these uncertainties. I'm going to start an RFC-based discussion for moving phpng to master so that the uncertainties around it are removed. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 7 Jul 2014, at 13:19, Pierre Joye wrote: > I am skeptical on bigint in the engine given what is possible now in > gmp. But yes, phpng is also a problem as it creates a total new code > base and barely blocks any other improvements. Why? Except that bigint > thing, I do not see many people trying to add stuff based on phpng at > this point, it is a moving target and will move a lot in the next > months as well. But this is a topic for another thread, this one being > about the version number and this exact RFC. The problem is that people who want to add stuff for PHP 6 feel they have to add it to phpng, because if phpng is to be PHP 6, then it would need to be based off that branch. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Mon, Jul 7, 2014 at 2:21 PM, Andrea Faulds wrote: > > On 7 Jul 2014, at 13:19, Pierre Joye wrote: > >> I am skeptical on bigint in the engine given what is possible now in >> gmp. But yes, phpng is also a problem as it creates a total new code >> base and barely blocks any other improvements. Why? Except that bigint >> thing, I do not see many people trying to add stuff based on phpng at >> this point, it is a moving target and will move a lot in the next >> months as well. But this is a topic for another thread, this one being >> about the version number and this exact RFC. > > The problem is that people who want to add stuff for PHP 6 feel they have to > add it to phpng, because if phpng is to be PHP 6, then it would need to be > based off that branch. Exactly, and for what I see, it is run forward and at some point we will see a post asking to replace master with phpng and use it as base for php6. To me this would be a bad thing, but this is the direction phpng is taking. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Mon, Jul 7, 2014 at 2:12 PM, Lester Caine wrote: > On 07/07/14 12:31, Pierre Joye wrote: >> I seriously hope that you take 2015 as pure example here. As I see no >> remote chance to be ready next year. PHPNG is a huge stack of >> undocumented perf patches far from being ready, APIs &code cleanup did >> not even begin, and the existing APIs are even more ugly. This is not >> going to be a small task, besides other things that we may like to >> have in the next major version. A 2 years development period sounds >> much more realistic to me. > > If that is a realistic roadmap, then what also needs to be added is just > what happens with the PHP5 in the meantime. From my own view, some > elements of 'PHP6' are still overdue, but if it will be yet another > couple of years then should we be looking at an interim solution for > 'bigint' and unicode? While reworking the entire code base to give a > performance improvement is a perfectly sensible long term plan it > sidesteps the 'problems' that PHPNext should ideally address. There are > perhaps two conflicting paths here? I am skeptical on bigint in the engine given what is possible now in gmp. But yes, phpng is also a problem as it creates a total new code base and barely blocks any other improvements. Why? Except that bigint thing, I do not see many people trying to add stuff based on phpng at this point, it is a moving target and will move a lot in the next months as well. But this is a topic for another thread, this one being about the version number and this exact RFC. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 07/07/14 12:31, Pierre Joye wrote: > I seriously hope that you take 2015 as pure example here. As I see no > remote chance to be ready next year. PHPNG is a huge stack of > undocumented perf patches far from being ready, APIs &code cleanup did > not even begin, and the existing APIs are even more ugly. This is not > going to be a small task, besides other things that we may like to > have in the next major version. A 2 years development period sounds > much more realistic to me. If that is a realistic roadmap, then what also needs to be added is just what happens with the PHP5 in the meantime. From my own view, some elements of 'PHP6' are still overdue, but if it will be yet another couple of years then should we be looking at an interim solution for 'bigint' and unicode? While reworking the entire code base to give a performance improvement is a perfectly sensible long term plan it sidesteps the 'problems' that PHPNext should ideally address. There are perhaps two conflicting paths here? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 7 Jul 2014, at 12:31, Pierre Joye wrote: > I seriously hope that you take 2015 as pure example here. As I see no > remote chance to be ready next year. PHPNG is a huge stack of > undocumented perf patches far from being ready, APIs &code cleanup did > not even begin, and the existing APIs are even more ugly. This is not > going to be a small task, besides other things that we may like to > have in the next major version. A 2 years development period sounds > much more realistic to me. I’m perhaps a little bit optimistic. ;) But yes. 2015 was just the earliest possible year that PHP NEXT could happen, though 2016 is probably more realistic. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
hi, On Sat, Jul 5, 2014 at 11:57 PM, Zeev Suraski wrote: > 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. I think it is not premature but also totally not important, but a matter of priorities I suppose... > 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'. Agree here, while my oppinion is clearly for 6, which is the next major version after 5, last time I checked. But as you said, no need to re do the discussions. > 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, I seriously hope that you take 2015 as pure example here. As I see no remote chance to be ready next year. PHPNG is a huge stack of undocumented perf patches far from being ready, APIs &code cleanup did not even begin, and the existing APIs are even more ugly. This is not going to be a small task, besides other things that we may like to have in the next major version. A 2 years development period sounds much more realistic to me. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 23:32, Kris Craig wrote: > 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. Sure. I’ve already said I’m willing to accept contributions, not just from Zeev. Heck, it’s a wiki, anyone with karma could edit if they liked (but please ask first). All I’m waiting for is said contributions. :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 23:38, Kris Craig wrote: > Oh and a quick question: Could you clarify how many voting choices there are > going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that a > "plurality" will be required for a win, which means that there should be at > least 3 or more choices. A plurality basically means that you got the most > votes even if it's less than 50%, which can only happen if there aer 3 or > more choices. Otherwise it's just a majority. Did you intend to list > another voting option? Or did you mean to say "simple majority" instead of > "plurality"? > > Here's a quick rundown of the terms in question: > > Super majority: Overwhelming support. Exact number varies. In the case of > PHP, it means 2/3 majority. > > Simple majority: 50% + 1 vote. > > Plurality: The most votes out of 3 or more choices, even if it's less than > 50%. In many elections systems, in the event of a plurality, the top two > vote-getters will be chosen from in a run-off election to ensure that the > final choice has majority support. Oops, my bad. The word “plurality” is indeed confusing in a two choice context. I’ve updated the section to clarify that there are only two votes, and used the phrase “simple majority”. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
Oh and a quick question: Could you clarify how many voting choices there are going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that a "plurality" will be required for a win, which means that there should be at least 3 or more choices. A plurality basically means that you got the most votes even if it's less than 50%, which can only happen if there aer 3 or more choices. Otherwise it's just a majority. Did you intend to list another voting option? Or did you mean to say "simple majority" instead of "plurality"? Here's a quick rundown of the terms in question: Super majority: Overwhelming support. Exact number varies. In the case of PHP, it means 2/3 majority. Simple majority: 50% + 1 vote. Plurality: The most votes out of 3 or more choices, even if it's less than 50%. In many elections systems, in the event of a plurality, the top two vote-getters will be chosen from in a run-off election to ensure that the final choice has majority support. --Kris
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
> > 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
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 18:37, Zeev Suraski wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
> On 6 ביול 2014, at 07:22, Andrea Faulds wrote: > > >> On 5 Jul 2014, at 22:23, Andrea Faulds wrote: >> >> 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. > I appreciate your change! As such I'd like to coauthor it with you and represent the case for 7. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
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 > On 6 ביול 2014, at 13:07, Andrea Faulds wrote: > > >>> On 6 Jul 2014, at 17:46, Lester Caine wrote: >>> >>> On 06/07/14 16:08, Andrea Faulds wrote: >>> 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. >> >> 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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 17:46, Lester Caine wrote: > On 06/07/14 16:08, Andrea Faulds wrote: >> 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. > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 06/07/14 16:08, Andrea Faulds wrote: > 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. 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 ... -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 16:12, Jocelyn Fournier wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 14:48, Lester Caine wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 06/07/14 12:21, Andrea Faulds wrote: > 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 - 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. 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? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 5 Jul 2014, at 22:23, Andrea Faulds wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 06/07/14 02:13, Zeev Suraski wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Sat, Jul 5, 2014 at 5:42 PM, Andrea Faulds wrote: > > On 6 Jul 2014, at 01:29, Kris Craig wrote: > > > 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. > > 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
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
> -Original Message- > From: Zeev Suraski [mailto:z...@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 > > > Argh, I need some sleep. I'll think about it further and respond in 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
> Argh, I need some sleep. I'll think about it further and respond in the morning. I think we have consensus here! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
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
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 02:04, Christoph Becker wrote: > Andrea Faulds wrote: > >> 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. > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
Andrea Faulds wrote: > 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. Have you considered a 6 vs. 7 vs. other vote, which would require a majority (i.e. > 50%) to pass? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 01:29, Kris Craig wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Sat, Jul 5, 2014 at 4:18 PM, Andrea Faulds wrote: > > On 6 Jul 2014, at 00:05, Zeev Suraski 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. > > 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
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
> -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 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
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 6 Jul 2014, at 00:05, Zeev Suraski 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. 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'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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
> 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. > > 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On 5 Jul 2014, at 22:57, Zeev Suraski wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Name of Next Release of PHP
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:a...@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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
