All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.
I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.
The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
Zeev
Hey:
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
I think this process is a little long.
we should freeze new features by the end of this year. then we could
release 7 asap
and regarding of the qa process, we can use 7.0.x to do that.
thanks
Zeev
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
I think this process is a little long.
we should freeze new features by the end of this year. then we could
release 7 asapand regarding of the qa process, we can use 7.0.x to do that.
thanks
Mmmm I don't think it is a good idea to rush the release.
At the starting point (so, something like one year ago), we had many
ideas to add to the new major PHP and had a compute of at least two
years development.
Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation
notices for examples.
Also, what about breaks in ABI ?
Have we ported every extension ? Have we written some doc to extension
writters ? Tools for them to ease migration ?
Last, some big parts - ideas we had - have not been taken in
consideration, nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engine
Quickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM - SPL rewrite and merging .... and many other ideas.
Julien.Pauli
Hey:
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.
do you remember how PHP6 dies?
thanks
The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
I think this process is a little long.
we should freeze new features by the end of this year. then we could
release 7 asapand regarding of the qa process, we can use 7.0.x to do that.
thanks
Mmmm I don't think it is a good idea to rush the release.
At the starting point (so, something like one year ago), we had many
ideas to add to the new major PHP and had a compute of at least two
years development.Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation
notices for examples.Also, what about breaks in ABI ?
Have we ported every extension ? Have we written some doc to extension
writters ? Tools for them to ease migration ?Last, some big parts - ideas we had - have not been taken in
consideration, nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engineQuickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM - SPL rewrite and merging .... and many other ideas.Julien.Pauli
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi!
do you remember how PHP6 dies?
I do. We failed to implement proper Unicode support. How is it relevant now?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
And:
Hey:
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.
we don't need to do all the ideas into PHP7. we will have 7.1, 7.2 eventually
thanks
The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
I think this process is a little long.
we should freeze new features by the end of this year. then we could
release 7 asapand regarding of the qa process, we can use 7.0.x to do that.
thanks
Mmmm I don't think it is a good idea to rush the release.
At the starting point (so, something like one year ago), we had many
ideas to add to the new major PHP and had a compute of at least two
years development.Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation
notices for examples.Also, what about breaks in ABI ?
Have we ported every extension ? Have we written some doc to extension
writters ? Tools for them to ease migration ?Last, some big parts - ideas we had - have not been taken in
consideration, nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engineQuickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM - SPL rewrite and merging .... and many other ideas.Julien.Pauli
--
Xinchen Hui
@Laruence
http://www.laruence.com/
At the starting point (so, something like one year ago), we had many ideas
to
add to the new major PHP and had a compute of at least two years
development.
Not every idea we have needs to go into 7.0. Specifically, only ideas that
require compatibility breakage have to go into 7.0, others can also go into
7.1 or later.
Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation notices
for examples.
We actually did several months ago. I think the majority of people agreed
that we should focus on 7.0, and only consider 5.7 if it became a necessity
due to a prolonged 7.0 timeline, which I think we should do our best to
avoid.
I don't think we should be introducing any (significant) compatibility
breakages into 7.0 that haven't already been deprecated as of 5.6.0. Most
users don't upgrade gradually and don't implement all minor versions anyway;
Personally, I don't think an interim version that you need to upgrade to
(5.7) and then upgrade yet again (7.0) will be very popular, to say the
least.
Have we ported every extension ?
Of course not. It's up to extension maintainers to update their extensions.
Have we written some doc to extension
writters ?
Yes.
Tools for them to ease migration ?
Not sure what you mean by that but if you have ideas, you're welcome!
Ultimately I think the only ingredient needed here is developer time, there
aren't magic shortcuts - nor is this an ultra-complicated task anyway.
Last, some big parts - ideas we had - have not been taken in
consideration,
nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engineQuickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM
- SPL rewrite and merging .... and many other ideas.
People who feel strongly enough about any of those ideas should turn them
into RFCs and run them through for approval/rejection. We can't wait on
tentative lists of ideas forever. The timeline I proposed provides ample
time to do that, which again, balances the importance of releasing this
major performance boosting update as early as possible, while taking
advantage of the opportunities associated with a new major version.
Zeev
At the starting point (so, something like one year ago), we had many ideas
to
add to the new major PHP and had a compute of at least two years
development.Not every idea we have needs to go into 7.0. Specifically, only ideas that
require compatibility breakage have to go into 7.0, others can also go into
7.1 or later.
Makes sense, however, we should absolutely be sure to integrate every
BC idea we'd like to into 7.0
If not , one will have to wait something like 10 years if we don't
allow BC breaks in 7.X minors.
Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation notices
for examples.We actually did several months ago. I think the majority of people agreed
that we should focus on 7.0, and only consider 5.7 if it became a necessity
due to a prolonged 7.0 timeline, which I think we should do our best to
avoid.I don't think we should be introducing any (significant) compatibility
breakages into 7.0 that haven't already been deprecated as of 5.6.0. Most
users don't upgrade gradually and don't implement all minor versions anyway;
Personally, I don't think an interim version that you need to upgrade to
(5.7) and then upgrade yet again (7.0) will be very popular, to say the
least.Have we ported every extension ?
Of course not. It's up to extension maintainers to update their extensions.
Sure I was talking about Core exts.
Have we written some doc to extension
writters ?Yes.
Tools for them to ease migration ?
Not sure what you mean by that but if you have ideas, you're welcome!
Ultimately I think the only ingredient needed here is developer time, there
aren't magic shortcuts - nor is this an ultra-complicated task anyway.
Ok, if something's been written (which seems to be the case), to
explain the big changes of internals, it is OK.
I could myself help on such parts, as when I'll start putting my head
into the new engine, I'll anyway review the whole source code, I could
at the same write docs.
Where is the actual migration doc you were talking about ?
Last, some big parts - ideas we had - have not been taken in
consideration,
nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engineQuickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM
- SPL rewrite and merging .... and many other ideas.
People who feel strongly enough about any of those ideas should turn them
into RFCs and run them through for approval/rejection. We can't wait on
tentative lists of ideas forever. The timeline I proposed provides ample
time to do that, which again, balances the importance of releasing this
major performance boosting update as early as possible, while taking
advantage of the opportunities associated with a new major version.
It depends on the idea, some are absolutely huge rewrites, like AIOs,
Unicode or Threads.
Some are easier whith lower impact, like rewriting the extension
system (task I have ideas about and would write and RFC about)
Julien.P
Hi:
Makes sense, however, we should absolutely be sure to integrate every
BC idea we'd like to into 7.0
If not , one will have to wait something like 10 years if we don't
allow BC breaks in 7.X minors.
I have to agree with Zeev that we shouldn't wait for things that might
or might not pop up, but keep track of any and act as appropriate if /
when they do. I know that's not what you're getting at, just wanted to
emphasize the point. Providing a formal list of what is being included /
excluded from 7.0 in this regard may also be useful so there is no
confusion later down the line.
At the same time, which I think has been discussed before, perhaps it's
time for a regular major release cycle (regular as in x (2-3?) years) so
that there is a timescale for when new changes (or ones that might be
intentionally or unintentionally missed / skipped for this major) that
wouldn't be allowed in minor releases can be proposed / written against?
Apologies for strictly being off-topic.
Ta.
Jonny.
At the same time, which I think has been discussed before, perhaps it's
time for a regular major release cycle (regular as in x (2-3?) years) so
that there is a timescale for when new changes (or ones that might be
intentionally or unintentionally missed / skipped for this major) that
wouldn't be allowed in minor releases can be proposed / written against?Apologies for strictly being off-topic.
In hindsight I still feel PHP5.4 should have been a new major version
which would have allowed a little more stability in the PHP5 stream,
while allowing more flexibility to make changes. I was always fobbed of
with 'It's only a number', but it IS a lot more than that. People are
now referring to a 10 year period for the next major, but 5 year steps
just seem a lot more manageable than 2 to 3 year steps?
--
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
Jonny Stirling wrote (on 14/10/2014):
At the same time, which I think has been discussed before, perhaps
it's time for a regular major release cycle (regular as in x (2-3?)
years) so that there is a timescale for when new changes (or ones that
might be intentionally or unintentionally missed / skipped for this
major) that wouldn't be allowed in minor releases can be proposed /
written against?Apologies for strictly being off-topic.
I actually think this is very much to the point. People keep saying "we
can always do it in 7.1", but that implies that we could already have
done it in 5.6 - i.e. it doesn't need a major version bump. What we
should really be saying is "we can always do it in 8.0", but I suspect
people are wary of saying that because it feels such a long way away.
So, if we keep the timeline for 7.0 short, it would be nice to have at
least tentative plan for how long before 8.0 - be it 3, 4, or 5 years.
That would give some hope for the features that don't make it into 7.0
not being completely forgotten, and hopefully relieve the pressure to
get it completely right this time.
As has been pointed out before, a clear timeline for major releases
would also allow much stricter enforcement of what is allowed in minor
releases. 7.1 and 7.2 could be true minors, knowing that 8.0 was just
around the corner with all the juicy bits in it.
Regards,
Rowan Collins
[IMSoP]
-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Tuesday, October 14, 2014 3:30 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: PHP 7.0 timelineJonny Stirling wrote (on 14/10/2014):
At the same time, which I think has been discussed before, perhaps
it's time for a regular major release cycle (regular as in x (2-3?)
years) so that there is a timescale for when new changes (or ones that
might be intentionally or unintentionally missed / skipped for this
major) that wouldn't be allowed in minor releases can be proposed /
written against?Apologies for strictly being off-topic.
I actually think this is very much to the point. People keep saying "we
can
always do it in 7.1", but that implies that we could already have done it
in 5.6
- i.e. it doesn't need a major version bump.
That depends on the feature in question. The only features/changes that
simply cannot make it into non-major releases are ones that break
compatibility. Ideally there shouldn't be too many of those, regardless of
our release timeline - to make the lives of our users easier.
What we should really be saying
is "we can always do it in 8.0", but I suspect people are wary of saying
that
because it feels such a long way away.
We should try to push most of those into 7.0. We shouldn't release 7.0 with
a long list of changes that we think should make it into 8.0. Instead, if
we know about a change that requires a major version change - we should
review it now, and decide for/against it. It's the
non-compatibility-breaking-changes that we can safely say can wait for 7.1,
because they can.
So, if we keep the timeline for 7.0 short, it would be nice to have at
least
tentative plan for how long before 8.0 - be it 3, 4, or 5 years.
That would give some hope for the features that don't make it into 7.0 not
being completely forgotten, and hopefully relieve the pressure to get it
completely right this time.As has been pointed out before, a clear timeline for major releases would
also allow much stricter enforcement of what is allowed in minor releases.
7.1 and 7.2 could be true minors, knowing that 8.0 was just around the
corner with all the juicy bits in it.
I think the 'juicy bits' comment suggests a possible misconception about
what major versions are, at least in their current definition. We can push
any type of juicy feature into a minor release, as long as it doesn't
break compatibility. We've introduced plenty of new features in the 5.x
family, including after we changed to the stricter rules on what can and
cannot make it into a minor version. We needed 7.0 because phpng, AST and
uniform variable syntax all break compatibility, although thankfully none of
them does it in a very significant manner. Also, historically major
versions also tended to bring performance improvements and substantial
engine refactoring. But still, new features, including fairly major ones
can make it into 7.x, exactly like they made it into 5.4/5.5/5.6.
Zeev
That depends on the feature in question. The only features/changes that
simply cannot make it into non-major releases are ones that break
compatibility. Ideally there shouldn't be too many of those, regardless of
our release timeline - to make the lives of our users easier.What we should really be saying
is "we can always do it in 8.0", but I suspect people are wary of saying
that
because it feels such a long way away.
We should try to push most of those into 7.0. We shouldn't release 7.0 with
a long list of changes that we think should make it into 8.0. Instead, if
we know about a change that requires a major version change - we should
review it now, and decide for/against it. It's the
non-compatibility-breaking-changes that we can safely say can wait for 7.1,
because they can.
Hi Zeev,
You are of course correct, a lot of changes can be made to minor
versions and have been in the past that don't require a major. That
doesn't change that there may be things missed (there may not, that's
not the point), or ideas that come up after GA or even at the last
minute e.g. in RCs or whatever that are wanted but have missed the 7
boat. Sure, get as much in as reasonably possible, but you potentially
can't get everything that comes up and you definitely can't get anything
that comes after release that requires a major. Some people may even be
keeping stuff back as you've provided a currently expected set of
changes. Nothing wrong with any of this, all is good.
If there is a cycle in place and thus an expected timeline / process for
after PHP7, then that surely makes the PHP7 timeline simpler to
manage, it gives a milestone for new ideas to be worked against and
more. If a good idea came through an RFC, but couldn't be done for PHP7,
the RFC would be dropped as there is nothing currently beyond that.
Tl;dr my thoughts are about after PHP7, which is itself looking pretty
good. I just don't want for the community, or the awesome internals devs
with great ideas walking away from things because there is no future plan.
Again, apologies for the side-track. It's not really specific to the
thread, but I still feel it's an important point.
Ta.
Jonny.
I think 1 year is reasonable timeline.
We still have 5 month for active development and implementation of new
ideas.
I think https://wiki.php.net/ideas/php6/engine is a bit outdated.
I'm not sure if anyone are going to work on proposals from 2009 (even if
they are great).
It would be great to define an ongoing set of changes that we would
definitely like to see in PHP-7.0 including the responsible person(s) and
time estimation. If something can't be developed by 7.0 release, it most
probably may wait for 7.1.
Thanks. Dmitry.
Hey:
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I
believe
it strikes a good balance between early delivery to stay competitive,
and
having enough time to shape a major version. Given that we’ve already
made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments
welcome!I think this process is a little long.
we should freeze new features by the end of this year. then we could
release 7 asapand regarding of the qa process, we can use 7.0.x to do that.
thanks
Mmmm I don't think it is a good idea to rush the release.
At the starting point (so, something like one year ago), we had many
ideas to add to the new major PHP and had a compute of at least two
years development.Also, we havent talked about a possible PHP 5.7, that could ease the
transition regading BC breaks brought by PHP7, issuing deprecation
notices for examples.Also, what about breaks in ABI ?
Have we ported every extension ? Have we written some doc to extension
writters ? Tools for them to ease migration ?Last, some big parts - ideas we had - have not been taken in
consideration, nor debatted. Some are listed here :
https://wiki.php.net/ideas/php6/engineQuickly put : Asynchronous IO and network code rewriting - PHP/Zend
Extension code rewrite - Introduction of threads into the VM, refactor
TSRM - SPL rewrite and merging .... and many other ideas.Julien.Pauli
At the starting point (so, something like one year ago), we had many
ideas to add to the new major PHP and had a compute of at least two
years development.
If we allow two years for development there will be too many changes
to make adoption easy. I think it's smarter to split it into 2x one
year developments (7.0 and 7.1), so that upgraders have a set of
stable features after one year that they can begin migration work
towards.
Hi!
we should freeze new features by the end of this year. then we could
release 7 asap
I think this is way too aggressive. This means basically next to nothing
that is not already has prepared RC gets into 7, since only discussion +
vote would take at least a month for anything substantial, and you have
to also work on RFC and patch. And not everybody has time to work on all
this fulltime, and some discussions can be slow or long-winded.
I think Zeev's timeline looks much better in this regard. I think GA
mid-October 2015 sounds a bit optimistic, but who knows, maybe it's me
that it too pessimistic :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hey:
Hi!
we should freeze new features by the end of this year. then we could
release 7 asapI think this is way too aggressive. This means basically next to nothing
that is not already has prepared RC gets into 7, since only discussion +
vote would take at least a month for anything substantial, and you have
to also work on RFC and patch. And not everybody has time to work on all
this fulltime, and some discussions can be slow or long-winded.
the problem here is, there is always new features if we wait...
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?
New features which missed PHP7.0, they can target at 7.1 instead.
thanks
I think Zeev's timeline looks much better in this regard. I think GA
mid-October 2015 sounds a bit optimistic, but who knows, maybe it's me
that it too pessimistic :)Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?
We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.
New features which missed PHP7.0, they can target at 7.1 instead.
Only features that preserve BC, which is a limiting factor.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.
There are also quite a few really low-level changes in master right now.
It is going to take quite a bit of time to stabilize. For example,
something as basic as array iteration is inadvertently different:
PHP is a mature project with reams and reams of legacy code out there.
Every single change, no matter how small, is like throwing a hand
grenade in a lake. There is the initial explosion and chaos and then the
ripples that go on and on. Dealing with all these ripples takes a lot
more time than most people think. For people who think that 1 year from
now is slow and conservative, it really isn't. It is quite aggressive
given the number of really low-level changes that are already in master.
Even if we froze the tree today I expect it could stretch to close to a
year to stabilize.
-Rasmus
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.There are also quite a few really low-level changes in master right now.
It is going to take quite a bit of time to stabilize. For example,
something as basic as array iteration is inadvertently different:
This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed:
https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5
PHP is a mature project with reams and reams of legacy code out there.
Every single change, no matter how small, is like throwing a hand
grenade in a lake. There is the initial explosion and chaos and then the
ripples that go on and on. Dealing with all these ripples takes a lot
more time than most people think. For people who think that 1 year from
now is slow and conservative, it really isn't. It is quite aggressive
given the number of really low-level changes that are already in master.
Even if we froze the tree today I expect it could stretch to close to a
year to stabilize.-Rasmus
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.There are also quite a few really low-level changes in master right now.
It is going to take quite a bit of time to stabilize. For example,
something as basic as array iteration is inadvertently different:This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed:
https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5
Yes, I am aware of that. I was using it to illustrate the point that
even with the changes currently in master, never mind any new things we
might add, we have a lot of work left to do before we are anywhere near
ready for a release.
-Rasmus
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.There are also quite a few really low-level changes in master right now.
It is going to take quite a bit of time to stabilize. For example,
something as basic as array iteration is inadvertently different:This is a known issue for which the test cases were marked as XFAIL because of the amount of work involved to get it fixed:
https://github.com/php/php-src/commit/5831cca9576f4e0d4daed75a9915d436dfc5f4e5
Yes, I am aware of that. I was using it to illustrate the point that
even with the changes currently in master, never mind any new things we
might add, we have a lot of work left to do before we are anywhere near
ready for a release.
I agree, we must absolutely provide something stable, solid,
performant and feature rich.
This will take time to stabilize and spot edge cases, some of them
could even lead to a reverse somewhere in the code.
Julien.Pauli
If we aren't able to fix a low-level problem in a year we most probably
won't be able to fix it in two as well.
Also, the closer we are to release, the more feedback we get, and the more
bugs are able to fix.
Delaying release would just reduce the attention of the users.
Thanks. Dmitry.
Hi!
IMO, AST, INT64, NG, Uniforme variables style is enough for a new
marjor version.. why we still need to wait?We don't need to just "wait", as sit and do nothing. We need to allocate
time for other features.There are also quite a few really low-level changes in master right now.
It is going to take quite a bit of time to stabilize. For example,
something as basic as array iteration is inadvertently different:PHP is a mature project with reams and reams of legacy code out there.
Every single change, no matter how small, is like throwing a hand
grenade in a lake. There is the initial explosion and chaos and then the
ripples that go on and on. Dealing with all these ripples takes a lot
more time than most people think. For people who think that 1 year from
now is slow and conservative, it really isn't. It is quite aggressive
given the number of really low-level changes that are already in master.
Even if we froze the tree today I expect it could stretch to close to a
year to stabilize.-Rasmus
hi Zeev,
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
Looks good to me. If we are done earlier, then good too. I will look
into the details later.
By the way, we were supposed to have one together to decide the 7
timeline and whether we wanted php 5.7,
https://wiki.php.net/rfc/php7_57_roadmap. I was waiting you for weeks
now after we discussed that with Andi. A little ping would have been
nice. Anyway, I will remove the 7 section on the other RFC and go for
it, if there are no other issue we cannot solve before voting,
--
Pierre
@pierrejoye | http://www.libgd.org
I like the 1 year timeline. It is an aggressive but achievable goal.
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
Zeev
--
Connect with me on http://twitter.com/jwage <http://twitter.com/jwage
hi Zeev,
All,
We’ve had some discussions about it during the version name & phpng RFC
processes, and now that 5.6.0 is behind us – I think it’s time to get a
more concrete game plan for PHP 7.0.I drafted an RFC that proposes a one year timeline for PHP 7.0. I believe
it strikes a good balance between early delivery to stay competitive, and
having enough time to shape a major version. Given that we’ve already made
some very substantial progress towards 7.0 (with phpng, AST, uniform
variable syntax, etc.) – I think that timeline is very realistic, and
perhaps we can even beat it. Restating the obvious, new features that
don’t have compatibility implications can always be delivered in minor
versions, i.e. 7.1, 7.2, etc.The RFC is at https://wiki.php.net/rfc/php7timeline - comments welcome!
So I have to say (again) that one year is too short. We discussed 1.5
year as a good realistic timeline and that's what I am going to
propose using a competitve RFC today, unless you are willing to add
the options to this RFC (would be easier). The need of a 5.7 release
is also something we need to decide.
I am not saying we cannot make it in less than 1.5 year, but one year,
given the current status, is not realistic. Given that the engine is
still a moving target, it is not realistic, fair nor correct to ask
other developers to get their stuff done by 2015/1 or 2015/2, it is
simply not the way I see cooperation and support for other php.net
developers.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org