Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Move the phpng branch to master »

[VOTE] Move the phpng branch to master

php.internals

Zeev Suraski

12 years ago
I opened the voting on the phpng RFC: https://wiki.php.net/rfc/phpng#vote Voting ends on Thursday, August 14th. Please vote! Zeev

Andrew Faulds

12 years ago
On 6 Aug 2014, at 13:36, Zeev Suraski <zeev@zend.com> wrote:
> I opened the voting on the phpng RFC: > > > > https://wiki.php.net/rfc/phpng#vote > > > > Voting ends on Thursday, August 14th.
I voted Yes, but I have to ask: Is there anything in master that’s not in phpng, i.e., is it completely up-to-date with the current master? Also, how are you guys doing with extension and SAPI support? Does phpdbg compile yet? (That’s particularly bugged me, I like having phpdbg because now I can view opcodes without needing vld, but it seems to be broken in ng.)
-- Andrea Faulds http://ajf.me/

Pierre Joye

12 years ago
hi Zeev, On Wed, Aug 6, 2014 at 2:38 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 6 Aug 2014, at 13:36, Zeev Suraski <zeev@zend.com> wrote: > >> I opened the voting on the phpng RFC: >> >> >> >> https://wiki.php.net/rfc/phpng#vote >> >> >> >> Voting ends on Thursday, August 14th. > > I voted Yes, but I have to ask: Is there anything in master that’s not in phpng, i.e., is it completely up-to-date with the current master? > > Also, how are you guys doing with extension and SAPI support? Does phpdbg compile yet? (That’s particularly bugged me, I like having phpdbg because now I can view opcodes without needing vld, but it seems to be broken in ng.)
As I am indeed in favor of having it in master sooner rather than later I really have a bad feeling about it right now. None of the questions I asked have been answered, like what is your roadmap? Pushing hard again to get the one year dev time for 7? The phpng RFC (and related pages) are not in a state where we could simply say yes to phpng without the risk to get things in we do not want (like the new argument parsing which is still in this branch). All in all, I all for moving phpng to master but not at this point, there are way too many unanswered questions and many of them are more than critical. Cheers,
-- Pierre @pierrejoye | http://www.libgd.org

Dmitry Stogov

12 years ago
Hi Andrea, On Wed, Aug 6, 2014 at 4:38 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 6 Aug 2014, at 13:36, Zeev Suraski <zeev@zend.com> wrote: > > > I opened the voting on the phpng RFC: > > > > > > > > https://wiki.php.net/rfc/phpng#vote > > > > > > > > Voting ends on Thursday, August 14th. > > I voted Yes, but I have to ask: Is there anything in master that’s not in > phpng, i.e., is it completely up-to-date with the current master? >
I made synchronization on this week. The very last master commits might be not in phpng yet. PHPNG must contain all the things from the master.
> > Also, how are you guys doing with extension and SAPI support?
Porting missing extensions and SAPIs is not in our priority list. We may provide some help for maintainers, but we are not going to do everything ourselves.
> Does phpdbg compile yet? (That’s particularly bugged me, I like having > phpdbg because now I can view opcodes without needing vld, but it seems to > be broken in ng.) >
We didn't port it. Thanks. Dmitry.

Derick Rethans

12 years ago
On Wed, 6 Aug 2014, Dmitry Stogov wrote:
> On Wed, Aug 6, 2014 at 4:38 PM, Andrea Faulds <ajf@ajf.me> wrote: > > > On 6 Aug 2014, at 13:36, Zeev Suraski <zeev@zend.com> wrote: > > > > > I opened the voting on the phpng RFC: > > > > > > https://wiki.php.net/rfc/phpng#vote > > > > > > Voting ends on Thursday, August 14th.
<snip>
> > Also, how are you guys doing with extension and SAPI support? > > Porting missing extensions and SAPIs is not in our priority list. We > may provide some help for maintainers, but we are not going to do > everything ourselves.
That's ok - how are the porting guidelines coming along though?
> > Does phpdbg compile yet? (That’s particularly bugged me, I like > > having phpdbg because now I can view opcodes without needing vld, > > but it seems to be broken in ng.) > > We didn't port it.
VLD works though ;-) cheers, Derick

Zeev Suraski

12 years ago
> -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Wednesday, August 06, 2014 3:57 PM > To: Dmitry Stogov > Cc: Andrea Faulds; Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master > > That's ok - how are the porting guidelines coming along though?
https://wiki.php.net/phpng-upgrading Not too bad for this stage I think... Zeev

Ferenc Kovacs

12 years ago
On Wed, Aug 6, 2014 at 2:38 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 6 Aug 2014, at 13:36, Zeev Suraski <zeev@zend.com> wrote: > > > I opened the voting on the phpng RFC: > > > > > > > > https://wiki.php.net/rfc/phpng#vote > > > > > > > > Voting ends on Thursday, August 14th. > > I voted Yes, but I have to ask: Is there anything in master that’s not in > phpng, i.e., is it completely up-to-date with the current master? >
master was last merged into phpng in http://git.php.net/?p=php-src.git;a=commit;h=7301994c28d548c5a4eda6a3a4ae0fab6af04636 two days ago.
> > Also, how are you guys doing with extension and SAPI support? Does phpdbg > compile yet? (That’s particularly bugged me, I like having phpdbg because > now I can view opcodes without needing vld, but it seems to be broken in > ng.) >
https://wiki.php.net/phpng#supported_sapi https://wiki.php.net/phpng#supported_extensions these are only the exts/sapis in the core, I think that adding support to the pecl exts should be a community effort.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Jonny Stirling

12 years ago
Zeev, I love how you've just completely ignored any previous discussion around the required majority issue. It's is certainly enlightening that questions specifically directed at you in multiple threads have gone unanswered when trying to work out which is actually required. Instead, you just take it on yourself to decide for everyone else. That's consideration for you. I mean, everybody else is wrong, right, so why worry about anything they say. My hat's (sarcastically) off to you sir. Jonny. P.s. Is this post un-useful? Perhaps. But it's not like a mail not infested with sarcasm is going make much difference.

Andrew Faulds

12 years ago
On 6 Aug 2014, at 13:47, Jonny Stirling <phoenix@jonstirling.co.uk> wrote:
> I love how you've just completely ignored any previous discussion around > the required majority issue.
Has it really been *ignored*? Just because someone wants something doesn’t mean you have to give it. Under Zeev’s (and as it so happens, my) interpretation of the voting process RFC, this does not need a 2/3 majority. phpng is not a language change, it is an implementation detail. Now, could Zeev make it have a 2/3 majority to be less controversial? Sure, but he doesn’t have to.
-- Andrea Faulds http://ajf.me/

Zeev Suraski

12 years ago
> -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Wednesday, August 06, 2014 3:51 PM > To: Jonny Stirling > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master > > > On 6 Aug 2014, at 13:47, Jonny Stirling <phoenix@jonstirling.co.uk>
wrote:
> > > I love how you've just completely ignored any previous discussion > > around the required majority issue. > > Has it really been *ignored*? Just because someone wants something
doesn't
> mean you have to give it. > > Under Zeev's (and as it so happens, my) interpretation of the voting
process
> RFC, this does not need a 2/3 majority. phpng is not a language change,
it is an
> implementation detail.
Fully agree with Andrea. I don't think there's a point in debating the majority question to no end, because ultimately, it's open for interpretation. I feel very, very confident about my interpretation - for reasons I explained already. I didn't ignore the feedback, I disagreed with it.
> Now, could Zeev make it have a 2/3 majority to be less controversial?
Sure,
> but he doesn't have to.
I still stand by my original comment - that I hope and believe this RFC will get well over 2/3 - but that it technically only requires a simple majority. Zeev

Pierre Joye

12 years ago
On Wed, Aug 6, 2014 at 2:59 PM, Zeev Suraski <zeev@zend.com> wrote:
> Fully agree with Andrea. I don't think there's a point in debating the > majority question to no end, because ultimately, it's open for > interpretation. I feel very, very confident about my interpretation - for > reasons I explained already. I didn't ignore the feedback, I disagreed > with it.
You disagree with questions? I call that self censorship. Very good lead.
>> Now, could Zeev make it have a 2/3 majority to be less controversial? > Sure, >> but he doesn't have to. > > I still stand by my original comment - that I hope and believe this RFC > will get well over 2/3 - but that it technically only requires a simple > majority.
A total rewamp of the engine, with some part of it being very disputable, some even had draft RFCs but looks like feedback for them are being ignored as well, and some BC as bonus? This requires 2/3. Period. And you will certainly get them, don't worry. And that's quite depressing about what's going on in php.net lately.
-- Pierre @pierrejoye | http://www.libgd.org

Dan Ackroyd

12 years ago
Hi, It would be good if people announced that they were going to open things to vote with a warning, rather than just throwing the voting open. The RFC is nowhere complete in it's details for people to make rational decisions. e.g. the section on 'RFC impact' has this for the impact on extensions. "Existing extensions will have to be updated to reflect the new data structures and updated APIs. Much of this work is already done for most of the extensions bundled with PHP, but there are still extensions that need to be ported, and most of the extensions in PECL will have to be ported." That doesn't provide anything close to actual information about what needs to be done to port the extensions. There is no information about how extensions can support current PHP and PHPNG at the same time....which they will need to do for the next couple of years at least. cheers Dan On 6 August 2014 13:36, Zeev Suraski <zeev@zend.com> wrote:

Zeev Suraski

12 years ago
Dan, Votes area almost never pre-announced. I have no problem with changing this habit, but I do have an issue with changing it retroactively for a particular vote. Regarding your points, there's a mandatory discussion period during which you should have brought these comments, instead of now. As a matter of fact, discussion about PHPNG died out more than a week ago, to the level that Dmitry even suggested we avoid wasting time and vote sooner (but that goes against the rules so we didn't do that). If you think the RFC is incomplete in its details and that you can't vote over it then you can of course withhold your vote or vote no. To your specific feedback, there's a migration document to extensions linked from the RFC, and shared here on internals about 10 days ago: https://wiki.php.net/phpng-upgrading I added another link to it from the 'RFC impact' section, as perhaps that's what prevented you from seeing it. I believe it's impractical to keep shared codebases for extensions between PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... Zeev

Dmitry Stogov

12 years ago
On Wed, Aug 6, 2014 at 5:11 PM, Zeev Suraski <zeev@zend.com> wrote:
> Dan, > > Votes area almost never pre-announced. I have no problem with changing > this > habit, but I do have an issue with changing it retroactively for a > particular vote. > > Regarding your points, there's a mandatory discussion period during which > you should have brought these comments, instead of now. As a matter of > fact, discussion about PHPNG died out more than a week ago, to the level > that Dmitry even suggested we avoid wasting time and vote sooner (but that > goes against the rules so we didn't do that). > > If you think the RFC is incomplete in its details and that you can't vote > over it then you can of course withhold your vote or vote no. > > To your specific feedback, there's a migration document to extensions > linked > from the RFC, and shared here on internals about 10 days ago: > https://wiki.php.net/phpng-upgrading > I added another link to it from the 'RFC impact' section, as perhaps that's > what prevented you from seeing it. > > I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... >
Some extension might require just few changes and they may share codebase for PHP and PHPNG, however it's going to be really difficult for very engine depended extensions like xdebug. Thanks. Dmitry.

Pierre Joye

12 years ago
On Wed, Aug 6, 2014 at 3:19 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> On Wed, Aug 6, 2014 at 5:11 PM, Zeev Suraski <zeev@zend.com> wrote: > >> Dan, >> >> Votes area almost never pre-announced. I have no problem with changing >> this >> habit, but I do have an issue with changing it retroactively for a >> particular vote. >> >> Regarding your points, there's a mandatory discussion period during which >> you should have brought these comments, instead of now. As a matter of >> fact, discussion about PHPNG died out more than a week ago, to the level >> that Dmitry even suggested we avoid wasting time and vote sooner (but that >> goes against the rules so we didn't do that). >> >> If you think the RFC is incomplete in its details and that you can't vote >> over it then you can of course withhold your vote or vote no. >> >> To your specific feedback, there's a migration document to extensions >> linked >> from the RFC, and shared here on internals about 10 days ago: >> https://wiki.php.net/phpng-upgrading >> I added another link to it from the 'RFC impact' section, as perhaps that's >> what prevented you from seeing it. >> >> I believe it's impractical to keep shared codebases for extensions between >> PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... >> > > Some extension might require just few changes and they may share codebase > for PHP and PHPNG, however it's going to be really difficult for very > engine depended extensions like xdebug.
For the exts I tried while I was testing/fixing phpng a couple of weeks ago, I'd to say that maintaining the same code base for phpng and 5.x is simply too hard, way too many APIs changes, many of them cannot be detected at compile time, introducing many many new #ifdefs along other things. I will maintain a separate branch. The only thing I worry about is how I will manage releases in pecl. I have no clean solution now, or maybe one release with two branches bundled. Separate releases could work too but I will try everything possible to do not have to do that, or to have to do that as it is really painful to do. Maybe I can manage to implement something in pickle to ease this work. Ideas welcome.
-- Pierre @pierrejoye | http://www.libgd.org

Andrew Faulds

12 years ago
On 6 Aug 2014, at 14:26, Pierre Joye <pierre.php@gmail.com> wrote:
> For the exts I tried while I was testing/fixing phpng a couple of > weeks ago, I'd to say that maintaining the same code base for phpng > and 5.x is simply too hard, way too many APIs changes, many of them > cannot be detected at compile time, introducing many many new #ifdefs > along other things. I will maintain a separate branch. The only thing > I worry about is how I will manage releases in pecl. I have no clean > solution now, or maybe one release with two branches bundled. Separate > releases could work too but I will try everything possible to do not > have to do that, or to have to do that as it is really painful to do. > Maybe I can manage to implement something in pickle to ease this work. > Ideas welcome.
Perhaps for these extensions, it is best to not make it work with both versions, but instead have a 5.x version and a phpng version, and continue to maintain both separately? I wonder if that might actually be less work than trying to keep a single version working on both.
-- Andrea Faulds http://ajf.me/

Pierre Joye

12 years ago
On Wed, Aug 6, 2014 at 3:45 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 6 Aug 2014, at 14:26, Pierre Joye <pierre.php@gmail.com> wrote: > >> For the exts I tried while I was testing/fixing phpng a couple of >> weeks ago, I'd to say that maintaining the same code base for phpng >> and 5.x is simply too hard, way too many APIs changes, many of them >> cannot be detected at compile time, introducing many many new #ifdefs >> along other things. I will maintain a separate branch. The only thing >> I worry about is how I will manage releases in pecl. I have no clean >> solution now, or maybe one release with two branches bundled. Separate >> releases could work too but I will try everything possible to do not >> have to do that, or to have to do that as it is really painful to do. >> Maybe I can manage to implement something in pickle to ease this work. >> Ideas welcome. > > Perhaps for these extensions, it is best to not make it work with both versions, but instead have a 5.x version and a phpng version, and continue to maintain both separately? I wonder if that might actually be less work than trying to keep a single version working on both.
This is what I just said. But the problem is then how to release them. An extension will release 2.0.0, how do you release it? 2.0.0-7 and 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The whole flow many projects uses now will have to change. This is something I have to think about, not sure what is the best solution yet.
-- Pierre @pierrejoye | http://www.libgd.org

Christian Stoller

12 years ago
From: Pierre Joye [mailto:pierre.php@gmail.com]
> On Wed, Aug 6, 2014 at 3:45 PM, Andrea Faulds <ajf@ajf.me> wrote: >> >> On 6 Aug 2014, at 14:26, Pierre Joye <pierre.php@gmail.com> wrote: >> >>> For the exts I tried while I was testing/fixing phpng a couple of >>> weeks ago, I'd to say that maintaining the same code base for phpng >>> and 5.x is simply too hard, way too many APIs changes, many of them >>> cannot be detected at compile time, introducing many many new #ifdefs >>> along other things. I will maintain a separate branch. The only thing >>> I worry about is how I will manage releases in pecl. I have no clean >>> solution now, or maybe one release with two branches bundled. Separate >>> releases could work too but I will try everything possible to do not >>> have to do that, or to have to do that as it is really painful to do. >>> Maybe I can manage to implement something in pickle to ease this work. >>> Ideas welcome. >> >> Perhaps for these extensions, it is best to not make it work with >> both versions, but instead have a 5.x version and a phpng version, >> and continue to maintain both separately? I wonder if that might actually >> be less work than trying to keep a single version working on both. > > This is what I just said. But the problem is then how to release them. > An extension will release 2.0.0, how do you release it? 2.0.0-7 and > 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The > whole flow many projects uses now will have to change. This is > something I have to think about, not sure what is the best solution > yet. > > -- > Pierre
I'd say the best way is to create a new major version for the extension branch which works with phpng. So 2.0.0 for normal and 3.0.0 for phpng. This would make it possible to maintain two branches for both versions. But I don't know if this is possible with pecl. Christian

Pierre Joye

12 years ago
On Aug 7, 2014 8:13 AM, "Christian Stoller" <stoller@leonex.de> wrote:
> > From: Pierre Joye [mailto:pierre.php@gmail.com] > > On Wed, Aug 6, 2014 at 3:45 PM, Andrea Faulds <ajf@ajf.me> wrote: > >> > >> On 6 Aug 2014, at 14:26, Pierre Joye <pierre.php@gmail.com> wrote: > >> > >>> For the exts I tried while I was testing/fixing phpng a couple of > >>> weeks ago, I'd to say that maintaining the same code base for phpng > >>> and 5.x is simply too hard, way too many APIs changes, many of them > >>> cannot be detected at compile time, introducing many many new #ifdefs > >>> along other things. I will maintain a separate branch. The only thing > >>> I worry about is how I will manage releases in pecl. I have no clean > >>> solution now, or maybe one release with two branches bundled. Separate > >>> releases could work too but I will try everything possible to do not > >>> have to do that, or to have to do that as it is really painful to do. > >>> Maybe I can manage to implement something in pickle to ease this work. > >>> Ideas welcome. > >> > >> Perhaps for these extensions, it is best to not make it work with > >> both versions, but instead have a 5.x version and a phpng version, > >> and continue to maintain both separately? I wonder if that might
actually
> >> be less work than trying to keep a single version working on both. > > > > This is what I just said. But the problem is then how to release them. > > An extension will release 2.0.0, how do you release it? 2.0.0-7 and > > 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The > > whole flow many projects uses now will have to change. This is > > something I have to think about, not sure what is the best solution > > yet. > > > > -- > > Pierre > > I'd say the best way is to create a new major version for the extension > branch which works with phpng. > So 2.0.0 for normal and 3.0.0 for phpng. This would make it possible > to maintain two branches for both versions. But I don't know if this is
possible
> with pecl.
Not sure. It means 5.x versions won't get any major version then, which is very unlikely for many exts. Cheers, Pierre

Levi Morrison

12 years ago
This is a just a reminder that voting ends on Thursday, August 14th.

Lester Caine

12 years ago
On 06/08/14 14:11, Zeev Suraski wrote:
> I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong...
Do we actually have a list of what is NOT going to work once this happens? I am still not in a position to test phpng myself simply because I rely on extensions that have not been ported yet and despite trying to work through all the new documentation I can't see as yet how I could do that work myself :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Dan Ackroyd

12 years ago
Hi Zeev,
>I have no problem with changing this >habit, but I do have an issue with changing it retroactively for a >particular vote.
Agreed, changing rules retroactively is bad. Considering improving practices for the future is good.
>To your specific feedback, there's a migration document to extensions linked >from the RFC, and shared here on internals about 10 days ago:
Thanks for that document. It would also be really useful if you could add a link to two commits of a non-trivial extension that has been migrated, with one commit before, and one commit after the migration. That would allow people like myself who only rarely dip into PHP internals to see the differences actually applied to code. cheers Dan On 6 August 2014 14:11, Zeev Suraski <zeev@zend.com> wrote:

Ferenc Kovacs

12 years ago
On Wed, Aug 6, 2014 at 5:38 PM, Dan Ackroyd <danack@basereality.com> wrote:
> Hi Zeev, > > >I have no problem with changing this > >habit, but I do have an issue with changing it retroactively for a > >particular vote. > > Agreed, changing rules retroactively is bad. Considering improving > practices for the future is good. > > >To your specific feedback, there's a migration document to extensions > linked > >from the RFC, and shared here on internals about 10 days ago: > > Thanks for that document. > > It would also be really useful if you could add a link to two commits > of a non-trivial extension that has been migrated, with one commit > before, and one commit after the migration. That would allow people > like myself who only rarely dip into PHP internals to see the > differences actually applied to code. >
git diff origin/master.. -- ext/curl (for example) is this really something which you think most voters would have trouble doing?
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Ferenc Kovacs

12 years ago
On Wed, Aug 6, 2014 at 5:50 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> > > > On Wed, Aug 6, 2014 at 5:38 PM, Dan Ackroyd <danack@basereality.com> > wrote: > >> Hi Zeev, >> >> >I have no problem with changing this >> >habit, but I do have an issue with changing it retroactively for a >> >particular vote. >> >> Agreed, changing rules retroactively is bad. Considering improving >> practices for the future is good. >> >> >To your specific feedback, there's a migration document to extensions >> linked >> >from the RFC, and shared here on internals about 10 days ago: >> >> Thanks for that document. >> >> It would also be really useful if you could add a link to two commits >> of a non-trivial extension that has been migrated, with one commit >> before, and one commit after the migration. That would allow people >> like myself who only rarely dip into PHP internals to see the >> differences actually applied to code. >> > > git diff origin/master.. -- ext/curl (for example) > is this really something which you think most voters would have trouble > doing? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
git diff origin/master..origin/phpng -- ext/curl is slightly better as it works independently from the current checkout.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Dmitry Stogov

12 years ago
hi Dan, you can look into the difference for each particular extension using git. e.g. git diff master..phpng -- ext/bcmath Thanks. Dmitry. On Wed, Aug 6, 2014 at 7:38 PM, Dan Ackroyd <danack@basereality.com> wrote:

Pascal MARTIN

12 years ago
Le 06/08/2014 14:36, Zeev Suraski a écrit :
> I opened the voting on the phpng RFC: > > https://wiki.php.net/rfc/phpng#vote > > Voting ends on Thursday, August 14th.
After speaking with other members of AFUP (French user-group) about this RFC, here's a short summary of our thoughts: The idea of (greatly: 20-30%) improving performances is really interesting, be it for performances themselves or for the reputation of the language. That's even more true if this gets us closer to JIT in the future. Having to update all extensions is not "perfect", but is not really a problem either: developers of extensions know this is to be expected for each major version of PHP -- and, after the branch is merged to master, they will still have something like two years to update their extensions. We are a bit sad this has been developed for quite some time in secret and the community has learned about it only after most of the work had been done: it doesn't really fit with the way we think about "open-source". Same thing about the fact several evolutions have all been worked on in the same branch, the same RFC and the same vote, instead of each being independent from the others. We feel there might have been too much "public" communication about "phpng" and its performance improvements, before the decision of merging it was (or not) taken. Because of this, at the time of the vote, we kind of feel like we don't have much of a choice: if the branch is not merged, PHP will look quite ridiculous, as "phpng" is already expected by many to be used as a a first step for PHP 7. Judging from some discussions here, we are afraid the quality and maintainability of PHP's source code might suffer a bit from this merge. For us, a major version is the right time (it's going to be used for something like 10 years) to work on those. (still, easy to say, when only a few of us contribute code to PHP). PHP 7 will be a "major" version. It must not be released earlier than planned only to publish some performance improvements as soon as possible (even if those are great). It is important to also think about features, reworks and other major improvements: with one major versions every 10 years, it's pretty much now or never! We would prefer PHP 7 to be released as a great version in two years, rather than seeing it too early in one year. In the end, there have been two opposite opinions on our UG's mailing-list -- and both are well represented, with strong posts on both "yes merge" and "no don't merge": * Some of us are OK to merge right now and improve things later, * While others would prefer to improve things now and merge only after. In any case, we all agree there is still a lot to be done before reaching PHP 7 ;-)
-- Pascal MARTIN http://blog.pascal-martin.fr @pascal_martin

Dmitry Stogov

12 years ago
Hi, According to voting result, phpng was merged into master and the version number was bumped to 7.0.0-dev. Thanks to contributors, testers, bloggers, voters and everyone evolved :) Thanks. Dmitry. On Wed, Aug 6, 2014 at 4:36 PM, Zeev Suraski <zeev@zend.com> wrote: