Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Dec 2, 2010 at 11:01 AM, Christopher Jones wrote: > > > On 11/26/2010 11:15 AM, Zeev Suraski wrote: >> >> 3. The motivation to skip 6 doesn't stem from marketing at all. The main >> motivation is that there's a VERY concrete perception amongst many users >> about what PHP 6 is. It's unlikely that PHP 6 will actually be that. >> Skipping this version makes perfect sense from just about any POV I can >> think of. That's actually one thing I do feel more strongly about - we >> should probably not reuse the version number 6.0 for something that's >> completely different than what we've been talking about for several years, >> whether it's now or anytime in the future. > > Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of > PHP 6 and therefore has unicode. So skipping the number "6" won't resolve > any user confusion. I think the unicode debacle will always give user's confusion, especially since there's many many PHP 6 books on bookshelves that speak of it. I think it's better to recognize what has happened with PHP 6, be honest to the community about what happened and why, and move on as best as we can. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 2 Dec 2010, at 19:46, "Christopher Jones" wrote: > > > On 12/02/2010 11:23 AM, James Butler wrote: >> Following that logic, they will expect the next major version number, >> whatever it is, to have Unicode. Nothing can be done about that apart from >> telling the world it won't, including it in, or let them find out for >> themselves... >> > > If we decide the next major version doesn't have unicode then we will > have to manage/expect some community confusion. This will happen > regardless of designated version number. > > Chris Sorry, I think I misinterpreted what you were saying. You are right, the user expectation will probably need to be managed, irrespective of major version number, for quite a few features that PHP6 was expected to bring, and also any features that will now arrive that are orthogonal to what PHP6 books/media have promised. That said if the next version is 7 / 2011 / whatever, at least it won't return stacks of obsolete and outdated articles, blog posts and books when people start googling it for help and information. Just my tuppence ha'penny. . > >> -- >> James Butler >> Sent from my iPhone >> >> On 2 Dec 2010, at 19:02, "Christopher Jones" >> wrote: >> >>> >>> >>> On 11/26/2010 11:15 AM, Zeev Suraski wrote: 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this version makes perfect sense from just about any POV I can think of. That's actually one thing I do feel more strongly about - we should probably not reuse the version number 6.0 for something that's completely different than what we've been talking about for several years, whether it's now or anytime in the future. >>> >>> Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of >>> PHP 6 and therefore has unicode. So skipping the number "6" won't resolve >>> any user confusion. >>> >>> Chris >>> >>> -- >>> Email: christopher.jo...@oracle.com >>> Tel: +1 650 506 8630 >>> Blog: http://blogs.oracle.com/opal/ >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> > > -- > Email: christopher.jo...@oracle.com > Tel: +1 650 506 8630 > Blog: http://blogs.oracle.com/opal/ > > -- > 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] Re: Hold off 5.4
On 12/02/2010 11:23 AM, James Butler wrote: Following that logic, they will expect the next major version number, whatever it is, to have Unicode. Nothing can be done about that apart from telling the world it won't, including it in, or let them find out for themselves... If we decide the next major version doesn't have unicode then we will have to manage/expect some community confusion. This will happen regardless of designated version number. Chris -- James Butler Sent from my iPhone On 2 Dec 2010, at 19:02, "Christopher Jones" wrote: On 11/26/2010 11:15 AM, Zeev Suraski wrote: 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this version makes perfect sense from just about any POV I can think of. That's actually one thing I do feel more strongly about - we should probably not reuse the version number 6.0 for something that's completely different than what we've been talking about for several years, whether it's now or anytime in the future. Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of PHP 6 and therefore has unicode. So skipping the number "6" won't resolve any user confusion. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Following that logic, they will expect the next major version number, whatever it is, to have Unicode. Nothing can be done about that apart from telling the world it won't, including it in, or let them find out for themselves... -- James Butler Sent from my iPhone On 2 Dec 2010, at 19:02, "Christopher Jones" wrote: > > > On 11/26/2010 11:15 AM, Zeev Suraski wrote: >> 3. The motivation to skip 6 doesn't stem from marketing at all. The main >> motivation is that there's a VERY concrete perception amongst many users >> about what PHP 6 is. It's unlikely that PHP 6 will actually be that. >> Skipping this version makes perfect sense from just about any POV I can >> think of. That's actually one thing I do feel more strongly about - we >> should probably not reuse the version number 6.0 for something that's >> completely different than what we've been talking about for several years, >> whether it's now or anytime in the future. > > Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of > PHP 6 and therefore has unicode. So skipping the number "6" won't resolve > any user confusion. > > Chris > > -- > Email: christopher.jo...@oracle.com > Tel: +1 650 506 8630 > Blog: http://blogs.oracle.com/opal/ > > > -- > 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] Re: Hold off 5.4
On 11/26/2010 11:15 AM, Zeev Suraski wrote: 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this version makes perfect sense from just about any POV I can think of. That's actually one thing I do feel more strongly about - we should probably not reuse the version number 6.0 for something that's completely different than what we've been talking about for several years, whether it's now or anytime in the future. Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of PHP 6 and therefore has unicode. So skipping the number "6" won't resolve any user confusion. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Sat, 2010-11-27 at 11:58 -0500, Matthew Weier O'Phinney wrote: > On 2010-11-26, Pierre Joye wrote: > > On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote: > > > 3. The motivation to skip 6 doesn't stem from marketing at all. The > > > main motivation is that there's a VERY concrete perception amongst > > > many users about what PHP 6 is. > > > > Leaving the very small conference crowd for a second: nobody never > > ever heard of php6 before the total fiasco a couple of months ago. > > Not true. There have been "PHP 6" books *published* and on the market > for literally years. While none of them mention Unicode in any meaningful way ;-) But well, the first thing is: "Do we want to go to a new major version number or not?" Only if we do the question for 6, 7, 42, ... is relevant. I interpret the discussion as more people favor 5.4. So the other discussion can be held when it is decided to change the major version. johannes (who will propose a key syntax change in a moment) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Sat, Nov 27, 2010 at 5:58 PM, Matthew Weier O'Phinney wrote: > On 2010-11-26, Pierre Joye wrote: >> On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote: >> > 3. The motivation to skip 6 doesn't stem from marketing at all. The >> > main motivation is that there's a VERY concrete perception amongst >> > many users about what PHP 6 is. >> >> Leaving the very small conference crowd for a second: nobody never >> ever heard of php6 before the total fiasco a couple of months ago. > > Not true. There have been "PHP 6" books *published* and on the market > for literally years. That's what I mentioned later on "except the php6 books" or something like that. I however keep the other comments, while many users have heard about unicode and php6, or the total fiasco a couple of months ago, they did not and still do not care about it. The php5 migration, adoption of 5.3, dealing with chaotic releases are what they talk about. But that's the feedback I got, maybe other hears something else, depending on the audience. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 2010-11-26, Pierre Joye wrote: > On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote: > > 3. The motivation to skip 6 doesn't stem from marketing at all. The > > main motivation is that there's a VERY concrete perception amongst > > many users about what PHP 6 is. > > Leaving the very small conference crowd for a second: nobody never > ever heard of php6 before the total fiasco a couple of months ago. Not true. There have been "PHP 6" books *published* and on the market for literally years. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/26/10 12:58 PM, Zeev Suraski wrote: >> Only that it has no technical or features- >> wise reasons to do so > > Substantial engine level improvements and a couple of new language level > features (it's pushing it a bit, I agree, but not that much) I think the next major version should be used to drop a bunch of deprecated features and to clean up some things. That's going to take a bit of time to figure out and agree on which means traits and the performance improvements are going to sit around unused for longer than if we get an interim version out there quicker. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 2:27 PM, Pierre Joye wrote: > On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote: > > > 3. The motivation to skip 6 doesn't stem from marketing at all. The main > motivation is that there's a VERY concrete perception amongst many users > about what PHP 6 is. > > Leaving the very small conference crowd for a second: nobody never > ever heard of php6 before the total fiasco a couple of months ago. Nobody ever heard of PHP 6? If you visit amazon.com and try search for "php 6", you'll see no less than 6 books (I stopped counting) all containing PHP 6 in the title. In the general PHP list, you'll see that developers reference PHP 6 when speaking of how to handle unicode, and how you will handle unicode in the future. If you search Google for "php 6", you'll be greeted with hundreds of blog posts speaking of how to prepare for the coming changes in PHP 6 or other aspects of its development. The title "PHP 6" has much baggage. The perception in the general community is strong and pervasive, and it certainly is not limited to a small conference crowd. Developers have strongly conceived expectations about what PHP 6 will entail, and as the releases creep towards an eventual 6.0, the growing divergence between the expectations and the actual releases will likely cause confusion and frustration. Given the expectations, the strength of the enhancements coming in this next release (significant engine rewrites, traits, APC, etc.), and the trend in nomenclature for software versions, I believe the case for jumping to a 7.0 release makes sense. I'm not an active contributor to the PHP core and I have no patches to my name, so I'm not sure what my vote is worth. However, I do actively help those on the general mailing list who are trying to learn basic PHP or are trying to troubleshoot new code, and it's the general developers in userland who will benefit from the most from the clear separation from the expectations. Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP-DEV] Re: Hold off 5.4
Zeev Suraski wrote: that's the crowd I referenced to. The users I discuss too, in locale conference, > UG, enterprises, etc. never heard or only vaguely about php6. Or they heard > about it while seeing a book called "PHP 6 and mysql 6" or something stupid > like that;). I've yet to meet someone in the last few years who knew about the PHP 6 project, and wasn't aware it was about unicoding PHP... People care about the roadmap of the products they're using. I'm not sure why you would think that the multi-year flagship version of PHP would remain a best-kept-secret. If you google for "PHP 6" it's clear beyond a reasonable doubt.. At the time that PHP5 was released PHP6 was being documented and roadmaped as the unicode path which would be in alpha 'in a couple of years time'. THAT is the documentation that was used as the basis of several premature books on PHP6. http://www.php.net/~derick/meeting-notes.html from the November 2005 meeting in Paris is what we were all expecting to follow PHP5 since PHP5 did NOT address the unicode problem that was well understood even back then -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> that's the crowd I referenced to. The users I discuss too, in locale > conference, > UG, enterprises, etc. never heard or only vaguely about php6. Or they heard > about it while seeing a book called "PHP 6 and mysql 6" or something stupid > like that ;). I've yet to meet someone in the last few years who knew about the PHP 6 project, and wasn't aware it was about unicoding PHP... People care about the roadmap of the products they're using. I'm not sure why you would think that the multi-year flagship version of PHP would remain a best-kept-secret. If you google for "PHP 6" it's clear beyond a reasonable doubt.. > > I've received countless questions about it from Japanese and Chinese > users. It's out there. If I had to bet based on my experience with users, > there are a lot more people that know what PHP 6 was supposed to be than > people who know its plans were scrapped. > > Same here, and that's one of the pandora box I want to open again. > Only not now, but not necessary in 2 years either. Hence the importance of > the RFC and clear, transparent process first. Given what I know about why we failed, and what alternatives exist, I wouldn't hold my breath. I'm too old to say it'll never happen, but I think I can say with a very high degree of confidence the chances of it happening within the next two years are very slim. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 9:58 PM, Zeev Suraski wrote: > I disagree. Google for "PHP 6". I've received tons of questions about it > from non-core-community attendees to conferences. that's the crowd I referenced to. The users I discuss too, in locale conference, UG, enterprises, etc. never heard or only vaguely about php6. Or they heard about it while seeing a book called "PHP 6 and mysql 6" or something stupid like that ;). > I've received countless questions about it from Japanese and Chinese users. > It's out there. If I had to bet based on my experience with users, there are > a lot more people that know what PHP 6 was supposed to be than people who > know its plans were scrapped. Same here, and that's one of the pandora box I want to open again. Only not now, but not necessary in 2 years either. Hence the importance of the RFC and clear, transparent process first. > I'll reply to some of your personal rant in person. It doesn't belong here... Rants? I only replied to "invented story". Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> Only that it has no technical or features- > wise reasons to do so Substantial engine level improvements and a couple of new language level features (it's pushing it a bit, I agree, but not that much) > but brings its lots of risks with it. I fail to see how changing a version number brings any risk at all. > Leaving the very small conference crowd for a second: nobody never ever > heard of php6 before the total fiasco a couple of months ago. I disagree. Google for "PHP 6". I've received tons of questions about it from non-core-community attendees to conferences. I've received countless questions about it from Japanese and Chinese users. It's out there. If I had to bet based on my experience with users, there are a lot more people that know what PHP 6 was supposed to be than people who know its plans were scrapped. I'll reply to some of your personal rant in person. It doesn't belong here... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote: > I'll begin again by saying I don't feel strongly about renaming 5.4 as 7.0, > but there are some important points worth bringing up: > > 1. The motivation for changing major version numbers was *never* BC breakage. > It was substantial language changes/additions and sometimes substantial > underlying engine changes. BC breakage was typically a side effect of that. No, but it was the main reasons. > 2. Marketing does not equate Evil. There's nothing bad about making good > moves that improve the perception of PHP in its userbase or the world at > large. Turning the current trunk version into a major version can be > perceived as a 'marketing' move - but that doesn't mean it's not legit. > Other than showing that the PHP project is moving along, there's also the > warm-fuzzy-feeling aspect, and based on the last couple of days it's clear > I'm not the only one that feels bad about being stuck in 5.x for over 6 years > with no change in sight. Right, and it was not meant badly. Only that it has no technical or features-wise reasons to do so but brings its lots of risks with it. > 3. The motivation to skip 6 doesn't stem from marketing at all. The main > motivation is that there's a VERY concrete perception amongst many users > about what PHP 6 is. Leaving the very small conference crowd for a second: nobody never ever heard of php6 before the total fiasco a couple of months ago. > What we call that version, whether it's PHP 5.4, PHP 7.0 or even PHP 3000, > shouldn't change the way we discuss contents for it. The fact I want to call > the very same thing we intend to release with a different name has absolutely > nothing to do with the pains we experimented with 5.3 or 6.0. Let say I know us too good and I don't think moving it to a major version will be of any help. > We can agree to disagree (and again - whatever - I'm fine with 5.4!), Right, but I really don't like that the feelings, wishes, requests and will of most of the active developers seem to be totally ignored by a couple of us. That's not what I like to see in a project like php.net. There is clearly a need to change the way we work, communicate and decide things (be releases, features, etc.). Like it or not, that's a fact. Other example, you do not want this type hinting, but what do you do to change that? Why do you simply ignore it? > but no need to invent unrelated horror stories :) Invent horror stories? Maybe you should take a bit more parts of the day to day releases and development to see that they are not invented stories :). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Friday, November 26, 2010 7:21 PM > To: Zeev Suraski > Cc: Ilia Alshanetsky; Johannes Schlüter; Andi Gutmans; Jani Taskinen; > da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski wrote: > >> -Original Message- > >> From: Pierre Joye [mailto:pierre@gmail.com] > >> Sent: Friday, November 26, 2010 3:03 AM > >> To: Ilia Alshanetsky > >> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; > >> da...@php.net; PHP Internals > >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 > >> > >> That can always be done later. > > > > Why do it later if we could do it now? :) > > > > Can you share some of the major things you think would constitute a > stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have > in the pipeline? > > Wait, why do you want a major version for something that does not break > BC, that only adds a couple of features (even long awaited like traits)? I > don't > see one. > > For a new major version I would rather first sort out the RFC, get the next > 5.x > out and then begin the discussions, designs, etc. Or are you looking to re do > all the mistakes and pains we experiment with 5.3.0 and ex.6.0.0? I won't go > down this way. > > About the "let drop the number 6" thing, that's just plain marketing and > really, that's the least problem our users have, or that we have. I'll begin again by saying I don't feel strongly about renaming 5.4 as 7.0, but there are some important points worth bringing up: 1. The motivation for changing major version numbers was *never* BC breakage. It was substantial language changes/additions and sometimes substantial underlying engine changes. BC breakage was typically a side effect of that. 2. Marketing does not equate Evil. There's nothing bad about making good moves that improve the perception of PHP in its userbase or the world at large. Turning the current trunk version into a major version can be perceived as a 'marketing' move - but that doesn't mean it's not legit. Other than showing that the PHP project is moving along, there's also the warm-fuzzy-feeling aspect, and based on the last couple of days it's clear I'm not the only one that feels bad about being stuck in 5.x for over 6 years with no change in sight. 3. The motivation to skip 6 doesn't stem from marketing at all. The main motivation is that there's a VERY concrete perception amongst many users about what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this version makes perfect sense from just about any POV I can think of. That's actually one thing I do feel more strongly about - we should probably not reuse the version number 6.0 for something that's completely different than what we've been talking about for several years, whether it's now or anytime in the future. What we call that version, whether it's PHP 5.4, PHP 7.0 or even PHP 3000, shouldn't change the way we discuss contents for it. The fact I want to call the very same thing we intend to release with a different name has absolutely nothing to do with the pains we experimented with 5.3 or 6.0. We can agree to disagree (and again - whatever - I'm fine with 5.4!), but no need to invent unrelated horror stories :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 6:21 PM, Pierre Joye wrote: > On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski wrote: >>> -Original Message- >>> From: Pierre Joye [mailto:pierre@gmail.com] >>> Sent: Friday, November 26, 2010 3:03 AM >>> To: Ilia Alshanetsky >>> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; >>> da...@php.net; PHP Internals >>> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >>> >>> That can always be done later. >> >> Why do it later if we could do it now? :) >> >> Can you share some of the major things you think would constitute a stronger >> reason to switch to 7 (or 11) than what we have in 5.4, that we have in the >> pipeline? > > Wait, why do you want a major version for something that does not > break BC, that only adds a couple of features (even long awaited like > traits)? I don't see one. To make it clear, I should have written: A release not breaking BC, as we can have a 5.4 release without BC breaks and with clear decisions about what we want to have in. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, Nov 26, 2010 at 4:46 PM, Zeev Suraski wrote: >> -Original Message- >> From: Pierre Joye [mailto:pierre@gmail.com] >> Sent: Friday, November 26, 2010 3:03 AM >> To: Ilia Alshanetsky >> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; >> da...@php.net; PHP Internals >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >> >> That can always be done later. > > Why do it later if we could do it now? :) > > Can you share some of the major things you think would constitute a stronger > reason to switch to 7 (or 11) than what we have in 5.4, that we have in the > pipeline? Wait, why do you want a major version for something that does not break BC, that only adds a couple of features (even long awaited like traits)? I don't see one. For a new major version I would rather first sort out the RFC, get the next 5.x out and then begin the discussions, designs, etc. Or are you looking to re do all the mistakes and pains we experiment with 5.3.0 and ex.6.0.0? I won't go down this way. About the "let drop the number 6" thing, that's just plain marketing and really, that's the least problem our users have, or that we have. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Derick Rethans [mailto:der...@php.net] > Sent: Friday, November 26, 2010 12:00 PM > To: Kalle Sommer Nielsen > Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; > da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > On Fri, 26 Nov 2010, Kalle Sommer Nielsen wrote: > > > 2010/11/25 Zeev Suraski : > > > I think that skipping to a major version is a good idea. > > > > > > Two key reasons I think that: > > > > > > 1. It'll help us break the evil spell of the 6 version number. > > > Honestly, I'm not so certain we'll have major engine rewrites the > > > size of what we've seen in PHP 3/4/5 going forward. Sure, I have a > > > track record for saying that in the past before PHP 5, but this time > > > I *really* think we've reached an evolutionary stage :). Even if > > > I'm wrong and we'd have a major rewrite happening, I don't think any > > > of us is seeing it any time soon. > > > > I also think that its appealing to skip to version 6 to break that > > spell once and for all. > > I think it's a bad idea. We'd just be scaring users because "new major > version" = break. We're not breaking a thing (or atleast, try not to). > And think about distrbutions that'd want to wait til 6.1 or something. I *think* that a good message is always easy to convey. 'Moving from 5.3 to 7.0 is a no brainer and is effortless' is easy to convey. Of course, I could be wrong... > We should reserve major versions for BC breaks. Just like we've always done. > I don't see the point of changing this, as it feels to me that you just want > to > change it because you want to change it. Even if we don't move a major version (or two) now, I think we should reconsider that major-version == major-breakage linkage. I'm not sure it holds true any longer, and may push us to be stuck in the 5.x realm for a very long time (as a matter of fact, we already are - since mid 2004 - with no change in sight). > Now, *if*, we would introduce breaking changes, skipping 6 might be a good > plan (and go straight to 7), but I don't see any sort of compelling reason why > you'd want to go to 6/7 now. No compelling reason. It's almost at the 'why not' level, and the only two reasons I have are the ones I stated in my previous email. We could go with 5.4 and the world won't stop spinning, I just think that going with 7.0 will have some benefits. Zeev
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Pierre Joye [mailto:pierre@gmail.com] > Sent: Friday, November 26, 2010 3:03 AM > To: Ilia Alshanetsky > Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen; > da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > That can always be done later. Why do it later if we could do it now? :) Can you share some of the major things you think would constitute a stronger reason to switch to 7 (or 11) than what we have in 5.4, that we have in the pipeline? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Pierre Joye wrote: > On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans wrote: > > >> This doesn't seem the ideal time to introduce a new toolchain, so > >> sticking with SVN, we should maintain 4 branches, 5.2 (security only), > >> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC > >> breaks), 6.0 (BC breaks). > > > > Four branches? Are you going to help? > > I'd to ask you to stop to say that in every 2nd person. What have you > done lately to help anyway? I don't understand why you're being so agressive. It was a honest question. More branches need more people to maintain it. And what is the problem with asking people for help? Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Fri, 26 Nov 2010, Kalle Sommer Nielsen wrote: > 2010/11/25 Zeev Suraski : > > I think that skipping to a major version is a good idea. > > > > Two key reasons I think that: > > > > 1. It'll help us break the evil spell of the 6 version number. > > Honestly, I'm not so certain we'll have major engine rewrites the > > size of what we've seen in PHP 3/4/5 going forward. Sure, I have a > > track record for saying that in the past before PHP 5, but this time > > I *really* think we've reached an evolutionary stage :). Even if > > I'm wrong and we'd have a major rewrite happening, I don't think any > > of us is seeing it any time soon. > > I also think that its appealing to skip to version 6 to break that > spell once and for all. I think it's a bad idea. We'd just be scaring users because "new major version" = break. We're not breaking a thing (or atleast, try not to). And think about distrbutions that'd want to wait til 6.1 or something. We should reserve major versions for BC breaks. Just like we've always done. I don't see the point of changing this, as it feels to me that you just want to change it because you want to change it. Now, *if*, we would introduce breaking changes, skipping 6 might be a good plan (and go straight to 7), but I don't see any sort of compelling reason why you'd want to go to 6/7 now. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Hi 2010/11/25 Zeev Suraski : > I think that skipping to a major version is a good idea. > > Two key reasons I think that: > > 1. It'll help us break the evil spell of the 6 version number. Honestly, > I'm not so certain we'll have major engine rewrites the size of what we've > seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that > in the past before PHP 5, but this time I *really* think we've reached an > evolutionary stage :). Even if I'm wrong and we'd have a major rewrite > happening, I don't think any of us is seeing it any time soon. I also think that its appealing to skip to version 6 to break that spell once and for all. While still having 5.4, with backported enhancements and features like Traits. Which also leaves us to the breakage point, allowing us to get rid of magic_quotes in trunk while its kept in 5.4. > > 2. Maybe it's time to break the notion that a major number change means > major breakage. Sometimes (like in Google Chrome), a major version can bring > nothing but a few new features and significantly improve performance, without > any additional pain. Not saying we should go to the extreme of releasing a > major version every other week, but once a year or once every 18 months is a > very reasonable frequency. > > Can't say I feel strongly about it, but I have a feeling that unless we > change our versioning scheme a slight bit, we'll be stuck in the 5.x realm > for a very long time (and I do think it actually reflects badly on the way > the language is perceived to some degree). > Although I don't feel strong about versioning either, but then I don't think it makes much sense to skip version 6 as suggested. 5.x is a major revision of PHP that we all like, but I won't want to be stuck in it forever either. Lets forget about the past PHP6 and make the present PHP6 happen instead. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
That can always be done later. Even if I don't think users care much about 6 or 7 being the version for the next major release. However for what I can read or hear, they care about traits and many of the points described in the RFC. Maybe we could focus on getting the RFC sorted out and figure out what can or should remain in a 5.4 release. We are almost ready to go with it, a matter of weeks. I fear that a major release is something we are not able to deal with right now. Then we can begin with the next major (call it php 11 if we like to, does not really matter ;) version. There are still plenty of work for it (we all have in mind at least one thing). On Fri, Nov 26, 2010 at 1:19 AM, Ilia Alshanetsky wrote: > I don't think the version # makes that much of a difference, but > rather what is in it. That said, people have made a good point that > jumping to something like 7, would allow us to skip the baggage > associated with PHP6, which seems like a fairly compelling argument to > me. > > On Thu, Nov 25, 2010 at 6:01 PM, Pierre Joye wrote: >> On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski wrote: >>> I think that skipping to a major version is a good idea. >> >> It is appealing but not a good idea. I think it is better to get 5.4 >> with the features we like in it and then consider a major version. >> There are quite a few things that we could add or changethat would >> justify a major version (without opening one of our pandora's boxes >> right now :). >> >> As of versioning scheme, yes, a clear and documented one is the way. >> Anything we can add to the RFC to clarify this would be welcome. Maybe >> start a new thread, it is getting hard to follow each topic. >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
I don't think the version # makes that much of a difference, but rather what is in it. That said, people have made a good point that jumping to something like 7, would allow us to skip the baggage associated with PHP6, which seems like a fairly compelling argument to me. On Thu, Nov 25, 2010 at 6:01 PM, Pierre Joye wrote: > On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski wrote: >> I think that skipping to a major version is a good idea. > > It is appealing but not a good idea. I think it is better to get 5.4 > with the features we like in it and then consider a major version. > There are quite a few things that we could add or changethat would > justify a major version (without opening one of our pandora's boxes > right now :). > > As of versioning scheme, yes, a clear and documented one is the way. > Anything we can add to the RFC to clarify this would be welcome. Maybe > start a new thread, it is getting hard to follow each topic. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > 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] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski wrote: > I think that skipping to a major version is a good idea. It is appealing but not a good idea. I think it is better to get 5.4 with the features we like in it and then consider a major version. There are quite a few things that we could add or changethat would justify a major version (without opening one of our pandora's boxes right now :). As of versioning scheme, yes, a clear and documented one is the way. Anything we can add to the RFC to clarify this would be welcome. Maybe start a new thread, it is getting hard to follow each topic. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Is it just unusually cold weather for this time of year or did the hell just freeze over? :-o Couldn't agree more on both points and I had the same thoughts about getting stuck with 5.x releases forever. And not getting any release out soon from trunk if this thread drags on too long. Maybe even skip 6 like Andi proposed and declare that from now even major versions are never released. Only prime numbers count. 7 is a prime number and it's the lucky one too. ;) --Jani p.s. Somehow this reminds me of one particular discussion in around 2001 about the versioning scheme.. :D 25.11.2010 23:56, Zeev Suraski wrote: I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). My 2c. Zeev -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010 7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP Internals Subject: RE: [PHP-DEV] Re: Hold off 5.4 On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: This is no different in the Java world, C++ as it matured or some other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- 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] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 16:56, Zeev Suraski wrote: > > Can't say I feel strongly about it, but I have a feeling that unless we > change our versioning scheme a slight bit, we'll be stuck in the 5.x realm > for a very long time (and I do think it actually reflects badly on the way > the language is perceived to some degree). Perl? Oh, PHP. -- http://www.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
I think that skipping to a major version is a good idea. Two key reasons I think that: 1. It'll help us break the evil spell of the 6 version number. Honestly, I'm not so certain we'll have major engine rewrites the size of what we've seen in PHP 3/4/5 going forward. Sure, I have a track record for saying that in the past before PHP 5, but this time I *really* think we've reached an evolutionary stage :). Even if I'm wrong and we'd have a major rewrite happening, I don't think any of us is seeing it any time soon. 2. Maybe it's time to break the notion that a major number change means major breakage. Sometimes (like in Google Chrome), a major version can bring nothing but a few new features and significantly improve performance, without any additional pain. Not saying we should go to the extreme of releasing a major version every other week, but once a year or once every 18 months is a very reasonable frequency. Can't say I feel strongly about it, but I have a feeling that unless we change our versioning scheme a slight bit, we'll be stuck in the 5.x realm for a very long time (and I do think it actually reflects badly on the way the language is perceived to some degree). My 2c. Zeev > -Original Message- > From: Johannes Schlüter [mailto:johan...@schlueters.de] > Sent: Thursday, November 25, 2010 7:55 PM > To: Andi Gutmans > Cc: Jani Taskinen; da...@php.net; PHP Internals > Subject: RE: [PHP-DEV] Re: Hold off 5.4 > > On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: > > This is no different in the Java world, C++ as it matured or some > > other technologies. > > Java is currently at 1.6. (and 6 in Marketing) :-) > C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting > for C++0x, whatever the actual name will be. > > No good examples ;-) > > johannes > > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 10:25 -0800, Rasmus Lerdorf wrote: > We also need that non-null zend_parse_parameters type implemented to > clean up the null-byte poisoning fixes in 5.3. Recently there was an off-list discussion about adding support for accepting non-empty strings only via zend_parse_parameters (zpp). There I raised the concern that we shouldn't add too many special validations for two main reasons: a) The more options zpp has the harder it is to use/read/maintain b) Errors from zpp usually are typically caused by program errors which in other languages for instance might be detected by a compiler not for being bad values as such errors might require different handling by the user. The null-byte thing is not only good for file operations but also for ereg and other places. But we should be sure about the error semantics caused. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 11:01 AM, Pierre Joye wrote: > I noticed it where functions accepts a path, do some checks (exists, > writable, etc.), resolves paths, etc. and then similar ops are done > again in a couple of places before we call the low level functions, > like in stream, tsrm for example, or extension using other extension's > streams. > > The idea is that file.absolute_path, file.original_path, or > file.resolved_path (example member names) will be passed to the low > level APIs, where each of them have been checked for NULL as well. Do you have an example? Also, these checks are going to hit the stat cache, so I don't think there is much to gain here. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf wrote: > On 11/25/10 10:43 AM, Pierre Joye wrote: >> On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans wrote: >>>> -Original Message- >>>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >>>> Sent: Thursday, November 25, 2010 10:26 AM >>>> To: Ilia Alshanetsky >>>> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP >>>> Internals >>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >>>> >>>> We also need that non-null zend_parse_parameters type implemented to clean >>>> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down >>>> much as >>>> it is pretty trivial. Just takes someone to sit down for a couple of >>>> hours and >>>> implementing it and finding all the places where parameters end up in >>>> paths. >>>> There are probably other places we don't want nulls either that currently >>>> have >>>> local checks that can be removed. >>> >>> Yes I agree. We may be able to skip this check for interned strings which >>> would be nice and potentially eliminate performance impact somewhat but >>> it's something that would need to be looked into. It's non-trivial but >>> doable (need to add a flag for interned strings whether they have a zero >>> byte or not). >> >> What do you think about a path argument? Returning something like >> zend_file_handle with some more meta info. Doing so will let us pass >> all the way down to the actual file API system call without having to >> duplicate opearions (stat, perms, etc.) as each ops will simply set >> the member accordingly. > > It wouldn't work in place of the non-null type. There are a number of > places where we are passing just filenames and it is up to the lower > level functions to figure out what to do with these and also places > where we just pass fragments or we pass stuff into things like the > session extension or database LOB calls. So, even if we did come up > with a zend_file_handle type, we would still need the non-null type for > all the places where we don't have a complete path. > > Also, I am curious where you think we have duplicate operations like that? I noticed it where functions accepts a path, do some checks (exists, writable, etc.), resolves paths, etc. and then similar ops are done again in a couple of places before we call the low level functions, like in stream, tsrm for example, or extension using other extension's streams. The idea is that file.absolute_path, file.original_path, or file.resolved_path (example member names) will be passed to the low level APIs, where each of them have been checked for NULL as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 10:46 AM > To: Andi Gutmans > Cc: Ilia Alshanetsky; Johannes Schlüter; da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > > Yes I agree. We may be able to skip this check for interned strings which > would be nice and potentially eliminate performance impact somewhat but it's > something that would need to be looked into. It's non-trivial but doable > (need to > add a flag for interned strings whether they have a zero byte or not). > > I'm not too worried about the performance impact here. Functions that need > these non-null strings need them because they are about to access the file > system in some way. The time it takes to check for nulls compared to the file > system access time is so small that I think we can safely ignore performance > issues. Yes I thought about that too after I sent the email :) It is negligible compared to the expensive filesystem operation. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 10:43 AM, Pierre Joye wrote: > On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans wrote: >>> -Original Message- >>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >>> Sent: Thursday, November 25, 2010 10:26 AM >>> To: Ilia Alshanetsky >>> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP >>> Internals >>> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >>> >>> We also need that non-null zend_parse_parameters type implemented to clean >>> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down >>> much as >>> it is pretty trivial. Just takes someone to sit down for a couple of hours >>> and >>> implementing it and finding all the places where parameters end up in paths. >>> There are probably other places we don't want nulls either that currently >>> have >>> local checks that can be removed. >> >> Yes I agree. We may be able to skip this check for interned strings which >> would be nice and potentially eliminate performance impact somewhat but it's >> something that would need to be looked into. It's non-trivial but doable >> (need to add a flag for interned strings whether they have a zero byte or >> not). > > What do you think about a path argument? Returning something like > zend_file_handle with some more meta info. Doing so will let us pass > all the way down to the actual file API system call without having to > duplicate opearions (stat, perms, etc.) as each ops will simply set > the member accordingly. It wouldn't work in place of the non-null type. There are a number of places where we are passing just filenames and it is up to the lower level functions to figure out what to do with these and also places where we just pass fragments or we pass stuff into things like the session extension or database LOB calls. So, even if we did come up with a zend_file_handle type, we would still need the non-null type for all the places where we don't have a complete path. Also, I am curious where you think we have duplicate operations like that? -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 10:33 AM, Andi Gutmans wrote: >> -Original Message- >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >> Sent: Thursday, November 25, 2010 10:26 AM >> To: Ilia Alshanetsky >> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP >> Internals >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >> >> We also need that non-null zend_parse_parameters type implemented to clean >> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down >> much as >> it is pretty trivial. Just takes someone to sit down for a couple of hours >> and >> implementing it and finding all the places where parameters end up in paths. >> There are probably other places we don't want nulls either that currently >> have >> local checks that can be removed. > > Yes I agree. We may be able to skip this check for interned strings which > would be nice and potentially eliminate performance impact somewhat but it's > something that would need to be looked into. It's non-trivial but doable > (need to add a flag for interned strings whether they have a zero byte or > not). I'm not too worried about the performance impact here. Functions that need these non-null strings need them because they are about to access the file system in some way. The time it takes to check for nulls compared to the file system access time is so small that I think we can safely ignore performance issues. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans wrote: >> -Original Message- >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >> Sent: Thursday, November 25, 2010 10:26 AM >> To: Ilia Alshanetsky >> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP >> Internals >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >> >> We also need that non-null zend_parse_parameters type implemented to clean >> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down >> much as >> it is pretty trivial. Just takes someone to sit down for a couple of hours >> and >> implementing it and finding all the places where parameters end up in paths. >> There are probably other places we don't want nulls either that currently >> have >> local checks that can be removed. > > Yes I agree. We may be able to skip this check for interned strings which > would be nice and potentially eliminate performance impact somewhat but it's > something that would need to be looked into. It's non-trivial but doable > (need to add a flag for interned strings whether they have a zero byte or > not). What do you think about a path argument? Returning something like zend_file_handle with some more meta info. Doing so will let us pass all the way down to the actual file API system call without having to duplicate opearions (stat, perms, etc.) as each ops will simply set the member accordingly. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 10:26 AM > To: Ilia Alshanetsky > Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP > Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > We also need that non-null zend_parse_parameters type implemented to clean > up the null-byte poisoning fixes in 5.3. I can't see this slowing us down > much as > it is pretty trivial. Just takes someone to sit down for a couple of hours > and > implementing it and finding all the places where parameters end up in paths. > There are probably other places we don't want nulls either that currently have > local checks that can be removed. Yes I agree. We may be able to skip this check for interned strings which would be nice and potentially eliminate performance impact somewhat but it's something that would need to be looked into. It's non-trivial but doable (need to add a flag for interned strings whether they have a zero byte or not). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 9:44 AM, Ilia Alshanetsky wrote: >> Looking through trunk I think we are in pretty good shape. I don't >> think cherry-picking and branch merging is an issue at this point. A >> 5.4 with the performance improvements, Traits, minus the type hinting >> breakage is something we can get out pretty quickly without causing any >> sort of PHP 6 confusion or breaking existing apps. >> >> -Rasmus > > I Second that. The 5.4 will be backwards compatible release to the 5.3 > code as far as PHP applications are concerned. The only items that > would be "broken" are deprecated features we may choose to remove like > register_globals,magic_quotes_gpc,etc... > > Having this release out, to let people realize the performance > benefits from core + apc bundling it offers would be supremely helpful > to all users of PHP. We also need that non-null zend_parse_parameters type implemented to clean up the null-byte poisoning fixes in 5.3. I can't see this slowing us down much as it is pretty trivial. Just takes someone to sit down for a couple of hours and implementing it and finding all the places where parameters end up in paths. There are probably other places we don't want nulls either that currently have local checks that can be removed. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote: > This is no different in the Java world, C++ as it matured or some > other technologies. Java is currently at 1.6. (and 6 in Marketing) :-) C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting for C++0x, whatever the actual name will be. No good examples ;-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
2010/11/25 Andi Gutmans : >> -Original Message- >> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >> Sent: Thursday, November 25, 2010 9:27 AM >> To: Johannes Schlüter >> Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >> >> Looking through trunk I think we are in pretty good shape. I don't think >> cherry- >> picking and branch merging is an issue at this point. A >> 5.4 with the performance improvements, Traits, minus the type hinting >> breakage is something we can get out pretty quickly without causing any sort >> of >> PHP 6 confusion or breaking existing apps. > > > Btw, just to be clear I am also OK with this approach. I just wanted to make > sure we consider the pros/cons of doing minor vs. major so we're all aligned > re: the implications :) I would pass on any type hinting patch because > there's no consensus and if we rip it out we are pretty much set to go (and I > do not see a major negative implication of taking it out). Less is more IMO > and it will enable us to get good functionality out sooner. We will probably > make some more engine enhancements during pre-beta but can freeze at any > point in time. Agreed here as well. I think we can begin with the release in January (I mean actually begin with the 1st test release). That lets us a couple of weeks (don't forget December has some family mandatory activities for most of us :) to actually get the RFC sorted out and review what we have. By review I mean to actually focus on evaluating trunk from a BC/QA/design point of view. I'm not saying it is badly designed or whatever else negative, but that most of us were busy with the current active branches and other bugs. I'm sure these 2-3 weeks more will benefit the php-next release and will make us feel much more confident about it, from day 1. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
> Looking through trunk I think we are in pretty good shape. I don't > think cherry-picking and branch merging is an issue at this point. A > 5.4 with the performance improvements, Traits, minus the type hinting > breakage is something we can get out pretty quickly without causing any > sort of PHP 6 confusion or breaking existing apps. > > -Rasmus I Second that. The 5.4 will be backwards compatible release to the 5.3 code as far as PHP applications are concerned. The only items that would be "broken" are deprecated features we may choose to remove like register_globals,magic_quotes_gpc,etc... Having this release out, to let people realize the performance benefits from core + apc bundling it offers would be supremely helpful to all users of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > Sent: Thursday, November 25, 2010 9:27 AM > To: Johannes Schlüter > Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > Looking through trunk I think we are in pretty good shape. I don't think > cherry- > picking and branch merging is an issue at this point. A > 5.4 with the performance improvements, Traits, minus the type hinting > breakage is something we can get out pretty quickly without causing any sort > of > PHP 6 confusion or breaking existing apps. Btw, just to be clear I am also OK with this approach. I just wanted to make sure we consider the pros/cons of doing minor vs. major so we're all aligned re: the implications :) I would pass on any type hinting patch because there's no consensus and if we rip it out we are pretty much set to go (and I do not see a major negative implication of taking it out). Less is more IMO and it will enable us to get good functionality out sooner. We will probably make some more engine enhancements during pre-beta but can freeze at any point in time. Andi
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Johannes Schlüter [mailto:johan...@schlueters.de] > Sent: Thursday, November 25, 2010 9:21 AM > To: Andi Gutmans > Cc: Jani Taskinen; da...@php.net; PHP Internals > Subject: RE: [PHP-DEV] Re: Hold off 5.4 > > On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: > > For what it's worth the changes we've made in the Zend Engine around > > performance and memory use could warrant a major version. Every major > > version of PHP in the past has been driven foremost by major engine > > overhauls. > > Yes, larger changes to the engine changed the major number. But all of them > had a big effect. This is "only" performance. No functionality. 90% of the > users > won't notice it. Whereas everbody oticed the change from3 to 4 or the new > object model in 5. Changing the major number has two big > effects: a) marketing b) more fear for doing the upgrade. > > I value b) as the more relevant factor to monitor. I agree it is border line. I didn't say I feel strongly about it but I also wouldn't dismiss the changes we are making in PHP-next both from a core runtime point of view, backwards compatibility + new functionality as a minor version. As technologies mature new major versions are often a bit more balanced which makes sense given we have such a huge user base. This is no different in the Java world, C++ as it matured or some other technologies. From a core runtime point of view I think the changes are actually quite far reaching. I also believe there's more that we can do and want to try and do. From a BC point of view I do think it's an opportunity to clean up quite a bit. I am not an advocate of going crazy but I think we've already identified a few areas as a group that we feel comfortable with that strike a good balance between BC and helping move things forward. I think these are major version changes not minor version changes. From a functionality point of view I actually think there's some good functionality here: - Traits (I think this is major) - Some additional language improvements around array dereferencing, configurable mbstring support at runtime (we still need to do some work there), closure enhancements, ... - Some major and minor improvements in modules such as FastCGI, JSON, hashing, ... I think this is definitely more than minor version. I agree it may feel somewhat light as a major version but there is no such thing as a manor version :) In the spirit of release early and often I would actually gravitate towards the major version and start with clean slate although I also understand the other side of the world. In this scenario I would not use the excuse of a major version to go crazy though. Keep it sane and similar to what we're discussing now with maybe some additional engine improvements, additional cleanup and some extension work that can probably still be done. It has to be extremely finite (short list) and managed in a good release process. I do think if we continue to do "major minor" versions like we've done in the 5.x branch we will probably stay in the 5.x branch perpetually and it could be confusing to our users when they get major BC breaks and changes within the same major version. Andi
Re: [PHP-DEV] Re: Hold off 5.4
hi Rasmus, 2010/11/25 Rasmus Lerdorf : > On 11/25/10 9:20 AM, Johannes Schlüter wrote: >> On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: >>> For what it's worth the changes we've made in the Zend Engine around >>> performance and memory use could warrant a major version. Every major >>> version of PHP in the past has been driven foremost by major engine >>> overhauls. >> >> Yes, larger changes to the engine changed the major number. But all of >> them had a big effect. This is "only" performance. No functionality. 90% >> of the users won't notice it. Whereas everbody oticed the change from3 >> to 4 or the new object model in 5. Changing the major number has two big >> effects: a) marketing b) more fear for doing the upgrade. >> >> I value b) as the more relevant factor to monitor. > > Looking through trunk I think we are in pretty good shape. I don't > think cherry-picking and branch merging is an issue at this point. A > 5.4 with the performance improvements, Traits, minus the type hinting > breakage is something we can get out pretty quickly without causing any > sort of PHP 6 confusion or breaking existing apps. Agreed, a php6 now just does not make sense, no matter from which point of view. I would not define 5.4 as being in a good shape but in a very promising shape to prepare a release. Removing the breakage, do some clear review of what we have (from a BC pov for one) and we could begin with a 5.4 release. However let get the RFC sorted out first before (it seems that we clearly have a consensus on most parts, time lines need to be adapted to avoid 5 releases at the same time :). Indeed, the type hint patch should be reverted as well, the sooner the better. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 11/25/10 9:20 AM, Johannes Schlüter wrote: > On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: >> For what it's worth the changes we've made in the Zend Engine around >> performance and memory use could warrant a major version. Every major >> version of PHP in the past has been driven foremost by major engine >> overhauls. > > Yes, larger changes to the engine changed the major number. But all of > them had a big effect. This is "only" performance. No functionality. 90% > of the users won't notice it. Whereas everbody oticed the change from3 > to 4 or the new object model in 5. Changing the major number has two big > effects: a) marketing b) more fear for doing the upgrade. > > I value b) as the more relevant factor to monitor. Looking through trunk I think we are in pretty good shape. I don't think cherry-picking and branch merging is an issue at this point. A 5.4 with the performance improvements, Traits, minus the type hinting breakage is something we can get out pretty quickly without causing any sort of PHP 6 confusion or breaking existing apps. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 6:11 PM, Andi Gutmans wrote: >> -Original Message- >> From: Jani Taskinen [mailto:jani.taski...@iki.fi] >> Sent: Thursday, November 25, 2010 12:25 AM >> To: da...@php.net >> Cc: PHP Internals >> Subject: Re: [PHP-DEV] Re: Hold off 5.4 >> >> Who says it has to be 5.4? People seem to be a bit fixated on the version >> there. >> Major BC breaks just means the version released from trunk is 6.0. And it's >> just >> a number. Big number, but still just a number. >> >> Merging (by and or by magic :) features into branch created from 5.3 just >> sounds like plane crash waiting to happen.. > > I agree and I don't think we're in as bad shape although there's some > cleaning up that needs to be done. It is not bad, it is only painful. I did the merges for 5.3.0-3 and I can tell you that SVN is simply broken for such things. I do it with git for many other projects and I never had real issues. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 15:11 +, Derick Rethans wrote: > > Yes, I also think trunk should be 5.4. It's not the most ideal thing > though, but something we'll have to live with. It's going to be a lot > less of a hassle than cherry picking trunk's features and graft them > onto 5.3. Agreed. Cherry picking from trunk is no option. For being able to do this one either needs feature branches or some strict rules for commit message (for instance "always refer to the relevant RFCs") so one can filter the commits properly. Changing to such a model doesn't belong in a discussion with "5.4" in the subject. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote: > For what it's worth the changes we've made in the Zend Engine around > performance and memory use could warrant a major version. Every major > version of PHP in the past has been driven foremost by major engine > overhauls. Yes, larger changes to the engine changed the major number. But all of them had a big effect. This is "only" performance. No functionality. 90% of the users won't notice it. Whereas everbody oticed the change from3 to 4 or the new object model in 5. Changing the major number has two big effects: a) marketing b) more fear for doing the upgrade. I value b) as the more relevant factor to monitor. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
> -Original Message- > From: Jani Taskinen [mailto:jani.taski...@iki.fi] > Sent: Thursday, November 25, 2010 12:25 AM > To: da...@php.net > Cc: PHP Internals > Subject: Re: [PHP-DEV] Re: Hold off 5.4 > > Who says it has to be 5.4? People seem to be a bit fixated on the version > there. > Major BC breaks just means the version released from trunk is 6.0. And it's > just > a number. Big number, but still just a number. > > Merging (by and or by magic :) features into branch created from 5.3 just > sounds like plane crash waiting to happen.. I agree and I don't think we're in as bad shape although there's some cleaning up that needs to be done. For what it's worth the changes we've made in the Zend Engine around performance and memory use could warrant a major version. Every major version of PHP in the past has been driven foremost by major engine overhauls. I believe there's quite a bit more that we can do during the pre-beta phase in these areas to strengthen that and those changes with a combination of traits, some cleanup of deprecated e.g. safe_mode could warrant a major new version. If we do go down that route I would advocate calling it PHP 7 and not PHP 6, not because I like jumping ahead so far (I don't like I am sure most people here don't) but we don't want people to search for PHP 6 and find past information which is not relevant to this version we release. Then again I can live with it either way but we should be aware of the negative implications there could be. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote: > On Thu, 25 Nov 2010, Davey Shafik wrote: > >> The goal then was to essentially take the 5.3 branch, create a 5.4 >> branch, cherry pick commits to trunk and apply them to the 5.4 branch >> and end up with a stable build. Unfortunately, subversion merging >> sucks. > > This has nothing to do with any sort of version control sucking. Cherry > picking is hard! It only works if you get one feature in one commit, > instead of many several, with other changes in between, without many > dependices between patches. PHP isn't like that, especially with > Dmitry's engine changing patches. While it's true the tools are not to blame, they're not HELPING the situation as much as some people seemed to think when the plan was thought out. Everything you say simply backs up my point that SVN is not the right tool for the model that seemed to be the goal. > >> This doesn't seem the ideal time to introduce a new toolchain, so >> sticking with SVN, we should maintain 4 branches, 5.2 (security only), >> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC >> breaks), 6.0 (BC breaks). > > Four branches? Are you going to help? I'm not sure why you seem to think this is so difficult. 5.2 would (ideally) have very little work going on. 5.3 would have somewhat more work, but is also closed to 5.4 so committing to two branches would be somewhat easier. 5.4 wouldn't be released till all features are complete, then it too moves to a bug fixes+security release and 5.2 gets sunsetted (this is why we need more reliable schedules). If we have releases every 6 months, or every 12 months (for example), it would mean each X.Y would last 12 or 24 months respectively. > >> Non-agreed upon enhancements, potential BC breaks, all should be done >> in feature branches. > > That's a good theoretical point of view. And I maintain it doesn't work. > It makes it for example very difficult to try out multiple new features > at the same time; to say, to try to figure our whethr your app will > still works. It's also a lot more egocentric thing, instead of > collaboration. You want your stuff exposed to as many developers as > possible (that's also why I am not a fan of DVCS, because it reduces > that exposure drastically). Actually, it makes things easier, now you can simply do: svn co http://svn.php.net/r/php/php-src/branches/PHP_5_3 php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/traits http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 svn diff http://svn.php.net/r/php/php-src/branches/derick-typehints http://svn.php.net/r/php/php-src/branches/PHP_5_3 | patch ./php-5.3 It means you get easy contiguous patches from any branch, over any number of commits (solving your issue above) And, as already pointed out, the collaboration possible through github is far more than we currently enjoy via SVN and ML/IRC today - but again, I don't want to propose git as a solution. As for talk of 6.0 as opposed to 5.4, nobody is going to risk putting their BC compatible features in a 6.0 release and then take 2 years to be adopted unless we force it (the committing to 6.0, not the adoption), when they can just create 5.5, 5.6, 5.14 and get it out before the stigma of the jump to 6.0 adoption. I don't have a solution for this that doesn't suck (forcing 6.0, or managing two branches, with all the same features, 5.x without the BC breaks, 6.0 with) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans wrote: >> This doesn't seem the ideal time to introduce a new toolchain, so >> sticking with SVN, we should maintain 4 branches, 5.2 (security only), >> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC >> breaks), 6.0 (BC breaks). > > Four branches? Are you going to help? I'd to ask you to stop to say that in every 2nd person. What have you done lately to help anyway? Besides the controversial patch for type hinting? Right, there is no point to ask you that, so I remove this question. Please, just respect everyone giving us precious feedback as well as other developers. >> Non-agreed upon enhancements, potential BC breaks, all should be done >> in feature branches. > > That's a good theoretical point of view. And I maintain it doesn't work. > It makes it for example very difficult to try out multiple new features > at the same time; to say, to try to figure our whethr your app will > still works. It's also a lot more egocentric thing, instead of > collaboration. You want your stuff exposed to as many developers as > possible (that's also why I am not a fan of DVCS, because it reduces > that exposure drastically). You mean more than putting an extension in some random personal repository? Be serious please. github and bitbucket are the two best examples why these tools are fantastic ways to ease contributions, both for the developers and the contributors. The requests procedure is simply amazing, there are also tools to review & manage external patches, with comments and history. That's simply impossible to do with svn. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Gustavo Lopes wrote: > On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans wrote: > > > On Thu, 25 Nov 2010, Davey Shafik wrote: > > > > > The goal then was to essentially take the 5.3 branch, create a 5.4 > > > branch, cherry pick commits to trunk and apply them to the 5.4 > > > branch and end up with a stable build. Unfortunately, subversion > > > merging sucks. > > > > This has nothing to do with any sort of version control sucking. > > Cherry picking is hard! It only works if you get one feature in one > > commit, instead of many several, with other changes in between, > > without many dependices between patches. PHP isn't like that, > > especially with Dmitry's engine changing patches. > > Yes, cherry picking is not as easy as people assume they are, because > many changes depend on each other and trunk has a fair quantity of > these. > > I think trunk should be the starting point for 5.4; as to type > hinting, I'm neutral as to the status quo. Yes, I also think trunk should be 5.4. It's not the most ideal thing though, but something we'll have to live with. It's going to be a lot less of a hassle than cherry picking trunk's features and graft them onto 5.3. > However, this is all orthogonal to this thread, what's important is > that we agree on the formalities proposed so that we can proceed to > these material issues. I don't know. The release process discussion can run at the same time and be ready for 5.5. That even allows us to refine it while we're trying out the current proposal. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans wrote: On Thu, 25 Nov 2010, Davey Shafik wrote: The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. Yes, cherry picking is not as easy as people assume they are, because many changes depend on each other and trunk has a fair quantity of these. I think trunk should be the starting point for 5.4; as to type hinting, I'm neutral as to the status quo. However, this is all orthogonal to this thread, what's important is that we agree on the formalities proposed so that we can proceed to these material issues. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Thu, 25 Nov 2010, Davey Shafik wrote: > The goal then was to essentially take the 5.3 branch, create a 5.4 > branch, cherry pick commits to trunk and apply them to the 5.4 branch > and end up with a stable build. Unfortunately, subversion merging > sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. > This doesn't seem the ideal time to introduce a new toolchain, so > sticking with SVN, we should maintain 4 branches, 5.2 (security only), > 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC > breaks), 6.0 (BC breaks). Four branches? Are you going to help? > Non-agreed upon enhancements, potential BC breaks, all should be done > in feature branches. That's a good theoretical point of view. And I maintain it doesn't work. It makes it for example very difficult to try out multiple new features at the same time; to say, to try to figure our whethr your app will still works. It's also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible (that's also why I am not a fan of DVCS, because it reduces that exposure drastically). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
May I ask not to begin with that again? The php 2034 thing? Let sort out what has to be sorted out, like the current proposals. In the short term, a 5.x (with BC) is what users and developers are looking for. We can then begin to think about the next big step. On Thu, Nov 25, 2010 at 1:58 PM, James Butler wrote: > Slightly brambly thoughts... > I think (imho) the PHP6 hype in user land died down long ago after it became > obvious it wouldn't materialise any time soon. It would be nice to see 6 to > appear if only to break the (apparent) deadlock that the Unicode stuff > brought on(I realise this is not enough justification by itself) > What will this mean to all the Hosting providers etc who are still finishing > long running 4->5 or 5.x -> 5.3 migrations? Will they resist change more > because it looks like a bigger change regardless of the underlying code? As > they provide installs/hosting for what I can guess to be a huge amount of the > PHP's actual users is it factor that's worth considering > > I realise this is a Friday afternoon category comment but it can't wait.. > Think of all of those PHP6 books that will be reduced to near junk status in > swift branch/commit action > And as a bonus > > -Original Message- > From: Jani Taskinen [mailto:jani.taski...@iki.fi] > > On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: > >> 2010/11/25 Jani Taskinen : >>> Who says it has to be 5.4? People seem to be a bit fixated on the version >>> there. >> >> I'd like to know too... >> >>> Major BC breaks just means the version released from trunk is 6.0. And it's >>> just a number. Big number, but still just a number. >> >> Well, such a change tends to create a big buzz, without mentioning >> stuff like certifications, trainings,... > > This is a joke, right? > >> We should avoid creating a virtual PHP 6.0 which will contain all the >> BC stuff while all features appears in 5.x. >> By doing so we will keep some shit in 5.x forever and won't have >> anything appealing enough to migrate to 6.0 > > ..or have something really new and interesting in PHP 7.0.0. The big version > number change is reserved for BC changing stuff, not just for "fancy new > stuff". > > --Jani > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
Slightly brambly thoughts... I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself) What will this mean to all the Hosting providers etc who are still finishing long running 4->5 or 5.x -> 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering I realise this is a Friday afternoon category comment but it can't wait.. Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action And as a bonus -Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: > 2010/11/25 Jani Taskinen : >> Who says it has to be 5.4? People seem to be a bit fixated on the version >> there. > > I'd like to know too... > >> Major BC breaks just means the version released from trunk is 6.0. And it's >> just a number. Big number, but still just a number. > > Well, such a change tends to create a big buzz, without mentioning > stuff like certifications, trainings,... This is a joke, right? > We should avoid creating a virtual PHP 6.0 which will contain all the > BC stuff while all features appears in 5.x. > By doing so we will keep some shit in 5.x forever and won't have > anything appealing enough to migrate to 6.0 ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff". --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: > 2010/11/25 Jani Taskinen : >> Who says it has to be 5.4? People seem to be a bit fixated on the version >> there. > > I'd like to know too... > >> Major BC breaks just means the version released from trunk is 6.0. And it's >> just a number. Big number, but still just a number. > > Well, such a change tends to create a big buzz, without mentioning > stuff like certifications, trainings,... This is a joke, right? > We should avoid creating a virtual PHP 6.0 which will contain all the > BC stuff while all features appears in 5.x. > By doing so we will keep some shit in 5.x forever and won't have > anything appealing enough to migrate to 6.0 ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff". --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
2010/11/25 Jani Taskinen : > Who says it has to be 5.4? People seem to be a bit fixated on the version > there. I'd like to know too... > Major BC breaks just means the version released from trunk is 6.0. And it's > just a number. Big number, but still just a number. Well, such a change tends to create a big buzz, without mentioning stuff like certifications, trainings,... We should avoid creating a virtual PHP 6.0 which will contain all the BC stuff while all features appears in 5.x. By doing so we will keep some shit in 5.x forever and won't have anything appealing enough to migrate to 6.0! > Merging (by and or by magic :) features into branch created from 5.3 just > sounds like plane crash waiting to happen.. > > ---Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Hold off 5.4
On 2010-11-23, Felipe Pena wrote:
> --001636eef065b3eaf30495ae5198
> Content-Type: text/plain; charset=UTF-8
>
> Given the current state of trunk, I think 5.4 release process should
> not begin tomorrow (alpha or whatever other status). There are
> numerous identified issues that we need to fix before even think to
> begin with a release. For example:
>
> - type hinting (or strict hinting)
> - no consensus
> - the RFCs are unclear
> - BC break introduced
> . classes named as any of the type hint scalar types
> do not work anymore
> aka class int {}
As Matthew pointed out, I consider this a pretty grave BC break.
> - Traits may not be ready yet for pre-release
> - see http://svn.php.net/viewvc?view=revision&revision=298348
> - APC support
>
> - There are many changes not BC with 5.x, as we allowed them for the
> development tree, before 5.4 was even a topic
>
> - APC is not yet bundled. Having the opcode bundle can raise issues by
> one or another, we should have it in from the very 1st release
>
> - pecl/http was planned to be bundled. What's the status?
>
> We also have no plan about what will or will not be 5.4. This looks
> familiar, this is exactly how we begun 5.3 and it tooks literally
> years to be released. There is also actually no agreement to begin
> with 5.4 now.
>
> 5.4 should be hold off until we solved the listed issues and the
> release management RFC gets discussed and hopefully approved.
+1, I agree. We should hold 5.4 off until we have at least a sane
release process and solve the type hinting question.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Who says it has to be 5.4? People seem to be a bit fixated on the version there. Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number. Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen.. ---Jani On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote: > > On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: > >> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote: >>> On 11/23/2010 02:30 AM, Felipe Pena wrote: >> 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. > > The reality is that trunk is not going to be 5.4; it cannot be in its current > state. > > The reason behind ditching the unicode php6 was to enable innovation in > trunk. This meant > we could have traits, type hinting, apc in core etc, as well as internal > enhancements, the new lemon > parser etc. Regardless of the arguments and unresolved issues, this IS > happening, and IS a good thing. > > The goal then was to essentially take the 5.3 branch, create a 5.4 branch, > cherry pick commits to trunk > and apply them to the 5.4 branch and end up with a stable build. > Unfortunately, subversion merging sucks. > > This is an unreliable, laborious, crappy method for creating stable branches, > and managing the > repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so > creating feature branches and > re-integrating is also a pretty crappy solution. > > So, with the BC breaks committed to trunk (register globals) or that we want > to commit to trunk (magic quotes), as > well as the code without consensus, creating a stable 5.4 branch is going to > be a lot of work. > > Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main > repo, but have several small projects on > github), but it seems that it's capabilities would make these things much > more trivial. Obviously: not a solution for now. > > We need to get our repo in order first, then we can start talking about 5.4. > The RMs need to make a definitive > stand about how the repo will be managed, and explain to us how that's going > to trickle down to our personal habits. > > This doesn't seem the ideal time to introduce a new toolchain, so sticking > with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes > + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). > > Non-agreed upon enhancements, potential BC breaks, all should be done in > feature branches. This gives people buildable > (hopefully) branches to use for testing, revision control for those > developing the features, and unmuddied commit histories > to more easily pull those changes into the appropriate branches. > > - Davey > -- > 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] Re: Hold off 5.4
2010/11/25 Davey Shafik : > > On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: > >> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote: >>> On 11/23/2010 02:30 AM, Felipe Pena wrote: >> 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. > > The reality is that trunk is not going to be 5.4; it cannot be in its current > state. > > The reason behind ditching the unicode php6 was to enable innovation in > trunk. This meant > we could have traits, type hinting, apc in core etc, as well as internal > enhancements, the new lemon > parser etc. Regardless of the arguments and unresolved issues, this IS > happening, and IS a good thing. > > The goal then was to essentially take the 5.3 branch, create a 5.4 branch, > cherry pick commits to trunk > and apply them to the 5.4 branch and end up with a stable build. > Unfortunately, subversion merging sucks. > > This is an unreliable, laborious, crappy method for creating stable branches, > and managing the > repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so > creating feature branches and > re-integrating is also a pretty crappy solution. > > So, with the BC breaks committed to trunk (register globals) or that we want > to commit to trunk (magic quotes), as > well as the code without consensus, creating a stable 5.4 branch is going to > be a lot of work. > > Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main > repo, but have several small projects on > github), but it seems that it's capabilities would make these things much > more trivial. Obviously: not a solution for now. > > We need to get our repo in order first, then we can start talking about 5.4. > The RMs need to make a definitive > stand about how the repo will be managed, and explain to us how that's going > to trickle down to our personal habits. > > This doesn't seem the ideal time to introduce a new toolchain, so sticking > with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes > + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). > > Non-agreed upon enhancements, potential BC breaks, all should be done in > feature branches. This gives people buildable > (hopefully) branches to use for testing, revision control for those > developing the features, and unmuddied commit histories > to more easily pull those changes into the appropriate branches. > > - Davey > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php I think Davey has a clear view and a good explanation about the current situation. Trunk has been used for both short and long term development hence the difficulties to agree that trunk is about 5.4 or +. In a first place, we should decide on what to have for 5.4 and what to leave for the future. A technical way to do it would be to use git-svn locally, starting from the PHP_5_3 branch and merging it with trunk. git rebase -i can then be used easily to remove all the commits we don't want to appear in 5.4. -- Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: > On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote: >> On 11/23/2010 02:30 AM, Felipe Pena wrote: > >>> 5.4 should be hold off until we solved the listed issues and the >>> release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote: > On 11/23/2010 02:30 AM, Felipe Pena wrote: >> 5.4 should be hold off until we solved the listed issues and the >> release management RFC gets discussed and hopefully approved. > > +1 +1 here too. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Hold off 5.4
On 11/23/2010 02:30 AM, Felipe Pena wrote: Given the current state of trunk, I think 5.4 release process should not begin tomorrow (alpha or whatever other status). There are numerous identified issues that we need to fix before even think to begin with a release. For example: ... We also have no plan about what will or will not be 5.4. This looks familiar, this is exactly how we begun 5.3 and it tooks literally years to be released. There is also actually no agreement to begin with 5.4 now. 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
