On Mon, Jul 21, 2014 at 3:47 PM, Zeev Suraski <z...@zend.com> wrote: d PHP NEXT. > > Everything I know about the PHP community, combined with the amazing level > of interest that the recent PHPNG benchmarks garnered, tells me that it > wrong.
You needed one year+ to stabilize opcache, how long will you need for something as huge as phpng? Along with giving the chance to other to actually do what we expect in the next major version? In my book it is more than a year, and between two and three years is a reasonable timeframe. > People would love to get it even if it was just the performance & memory > footprint gains alone. And we're not even talking about that - we'd still > have ample time to put in additional features into it. People tells me something else. But we surely speak to totally different people. >> There are a lot of big changes we can and should make and >> that would necessitate delaying it. Three years might be a bit long. > > Three years is a lifetime in our world of software... Are nothing. > Even if it's going to be 18 months (which is on the upper limit of what I > think we should allow for .NEXT), I don't see a need for 5.7 in between. It is per se defined to have a 5.7 next year. I do not see how it could be remotely possible to have php-next ready by June 2015, except if you release something not ready and did the same that we did before "we will fix/clean that later", which indeed never happened. > When we created the release process RFC, from the get go, I thought that > releasing every 12 months is too frequent. I was told not to worry and > that we'll "see how it goes" and "change if we need to". We can adapt the RFC, not let a company adapts it as they wish as you seems to like to do. > Now, suddenly > this became a God-given commandment, that we must have a mini version > every year and on time - and it's not. Reality is that the userbase is > embracing versions a lot slower than we crank them up - releasing 5.7 to > be followed shortly by 6/7 doesn't make a lot of sense, I think. Adoption of new versions is increasing, drastically, because of the release process RFC. That is what many major big companies using PHP tell me as well as what the numbers I can see tell me. > Still, I think we're much better off delivering .NEXT as soon as we can > as. As soon as we can? Hell yeah. I cannot agree more here. And as soon as we can is not as soon as you wish or as soon as you consider phpng release ready (in theory). >> > This is the assumption we should take IMHO, and only branch 5.7 (and >> > more importantly, invest time in it) if it proves wrong. >> >> Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if > some RFCs >> pass, we can merge them into 5.7. It also gives us a fallback. If PHP > NEXT >> doesn't happen next year (and I expect that it won't), we'll still have > 5.7. > > I can live with that, as long as we treat 5.7 as a secondary project where > we backport stuff rom master, and as long as it's clear to everyone that > it may be (or IMHO may very well be) throw-away code that we'll never > actually use. Personally I think it makes more sense to focus on getting > .NEXT out the door quickly so that we don't have to get into the headache > of working on two active trees, though. I'd like to see what others are > thinking... I have no issue working with many trees, CIs get better every day, testing PRs are now automated, travis support for more platforms is coming, everything coming together to increase php and related projects quality. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
