Good evening,
I’ve kept putting this off, but given the current “move phpng to master” vote, I really can’t delay this any longer.
It looks like PHP 7 is going to happen and phpng will be the base of that. While we could move straight to PHP 7 after the release of PHP 5.6, I think there is some merit in having one more 5.x release, namely 5.7, which would follow our usual release process and come out next year.
PHP 7, as a major release, is likely to take much longer than a usual minor release. While some people might think one year is realistic, I highly doubt that, as I suspect phpng will not be the only new feature PHP 7 will contain. Major releases come with major changes, and I suspect some others will crop up, and these might delay the release. Because it will probably take two to three years, having a minor release in the meantime means userland developers won’t be starved of new features which don’t need to be in a major release and could be in a minor.
Another point is that PHP 7 is probably going to break backwards-compatibility more significantly than minors would. For starters, phpng will break extension compatibility, and new proposals are likely to break userland compatibility as well. By making 5.7 happen, developers will have more time to switch to PHP 7 and can keep their existing codebases for longer.
As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add deprecation warnings and such to help people prepare for 7.
Finally, it is a fallback. If we do end up targeting 7 to come out next year, then if serious issues cause delays to 7, we will have a less ambitious and working new release to fall back on.
I should clarify that I don’t wish to delay phpng at all, I am very much in favour of it and excited about it, nor do I expect this to delay it. We can simply work on two releases at once: PHP 7, an ambitious BC-breaking release to come out later, and PHP 5.7, a safe, non-breaking release that will come out next year with the usual schedule.
Thoughts? Thanks!
Andrea Faulds
http://ajf.me/
As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add deprecation warnings and such to help people prepare for 7.
The updated multiple default blocks in a switch statement proposes
exactly this. Even if PHP 5.7 doesn't have any features I think it
would make the transition to PHP 7 easier.
As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add deprecation warnings and such to help people prepare for 7.
The updated multiple default blocks in a switch statement proposes
exactly this. Even if PHP 5.7 doesn't have any features I think it
would make the transition to PHP 7 easier.
Right. The specification is a general motivation for 5.7 for me, actually. By specifying PHP we spot a lot of things that need fixing, and 5.7 is a good time to fix them or note that we’re going to fix them. That means we don’t have these loose ends lying around as specified behaviour for two or three years. It could also be the first version of PHP which would have the official specification and implementation released at the same time, I hope. :)
Andrea Faulds
http://ajf.me/
I’ve kept putting this off, but given the current “move phpng to
master” vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of
that. While we could move straight to PHP 7 after the release of PHP
5.6, I think there is some merit in having one more 5.x release,
namely 5.7, which would follow our usual release process and come out
next year.
Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The momentum is here now, let's use it to get PHP 7
ready—instead of bogging ourselves down with a PHP 5.7.
cheers,
Derick
I’ve kept putting this off, but given the current “move phpng to
master” vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of
that. While we could move straight to PHP 7 after the release of PHP
5.6, I think there is some merit in having one more 5.x release,
namely 5.7, which would follow our usual release process and come out
next year.Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The momentum is here now, let's use it to get PHP 7
ready—instead of bogging ourselves down with a PHP 5.7.
It is not going to be one year. This is insane to consider php7 as ng only.
And we need 5.7 anyway to prepare 7, as stated numerous time already.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, August 15, 2014 12:25 PM
To: Andrea Faulds
Cc: PHP internals
Subject: Re: [PHP-DEV] Let's make a 5.7 releaseI’ve kept putting this off, but given the current “move phpng to
master” vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of
that. While we could move straight to PHP 7 after the release of PHP
5.6, I think there is some merit in having one more 5.x release,
namely 5.7, which would follow our usual release process and come out
next year.Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The
momentum is here now, let's use it to get PHP 7 ready—instead of bogging
ourselves down with a PHP 5.7.
Exactly.
Zeev
I’ve kept putting this off, but given the current “move phpng to
master” vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of
that. While we could move straight to PHP 7 after the release of PHP
5.6, I think there is some merit in having one more 5.x release,
namely 5.7, which would follow our usual release process and come out
next year.Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The momentum is here now, let's use it to get PHP 7
ready—instead of bogging ourselves down with a PHP 5.7.
we don't have a single instance where we were able to deliver a minor
release under a year, and I'm fairly sure that 7.0 will see more proposed
features/changes as any previous minor, because there are stuff which can
only happen in a major version.
More changes(both in numbers and in impact) will need more time to
stabilize, so I think that the one year roadmap for 7.0 is unrealistic.
You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm
fairly sure that 5.7 would be the smallest of the 5.x minor versions for
two reasons: we are getting better with not letting BC breaks slip in in
minors plus working on a major version is much more interesting as you have
less restrictions, so I think that 5.7 will/would be only to make the bed
for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small
features.
I think that there is no reason to give up our current release policy and
roadmap, and bet everything on PHP7, we don't lose anything with keeping
5.7.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I’ve kept putting this off, but given the current “move phpng to
master” vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of
that. While we could move straight to PHP 7 after the release of PHP
5.6, I think there is some merit in having one more 5.x release,
namely 5.7, which would follow our usual release process and come out
next year.Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The momentum is here now, let's use it to get PHP 7
ready—instead of bogging ourselves down with a PHP 5.7.we don't have a single instance where we were able to deliver a minor
release under a year, and I'm fairly sure that 7.0 will see more proposed
features/changes as any previous minor, because there are stuff which can
only happen in a major version.
More changes(both in numbers and in impact) will need more time to
stabilize, so I think that the one year roadmap for 7.0 is unrealistic.
You seem to be arguing that 5.7 would pull away resources from 7.0, but
I'm
fairly sure that 5.7 would be the smallest of the 5.x minor versions for
two reasons: we are getting better with not letting BC breaks slip in in
minors plus working on a major version is much more interesting as you
have
less restrictions, so I think that 5.7 will/would be only to make the bed
for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small
features.
I think that there is no reason to give up our current release policy and
roadmap, and bet everything on PHP7, we don't lose anything with keeping
5.7.
I cannot agree more with you here.
And the delay something like bundling opcache needed almost 300% more time
than what was promised. I won't even imagine what phpng will be in we rush
it.
Cheers,
Pierre
Basically, you're wanting to give up hope on PHP 7 in one year at the
moment it is started... I think that's a pretty big mistake to do this
already. The momentum is here now, let's use it to get PHP 7
ready—instead of bogging ourselves down with a PHP 5.7.we don't have a single instance where we were able to deliver a minor
release under a year, and I'm fairly sure that 7.0 will see more proposed
features/changes as any previous minor, because there are stuff which can
only happen in a major version.
More changes(both in numbers and in impact) will need more time to
stabilize, so I think that the one year roadmap for 7.0 is unrealistic.
You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm
fairly sure that 5.7 would be the smallest of the 5.x minor versions for
two reasons: we are getting better with not letting BC breaks slip in in
minors plus working on a major version is much more interesting as you have
less restrictions, so I think that 5.7 will/would be only to make the bed
for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small
features.
I think that there is no reason to give up our current release policy and
roadmap, and bet everything on PHP7, we don't lose anything with keeping
5.7.
I can’t agree more with this, you’ve put it better than I did.
--
Andrea Faulds
http://ajf.me/
--001a11c1258a38c82a0500a8b070
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
we don't have a single instance where we were able to deliver a minor
release under a year, and I'm fairly sure that 7.0 will see more proposed
features/changes as any previous minor, because there are stuff which can
only happen in a major version.
More changes(both in numbers and in impact) will need more time to
stabilize, so I think that the one year roadmap for 7.0 is unrealistic.
You seem to be arguing that 5.7 would pull away resources from 7.0, but I'm
fairly sure that 5.7 would be the smallest of the 5.x minor versions for
two reasons: we are getting better with not letting BC breaks slip in in
minors plus working on a major version is much more interesting as you have
less restrictions, so I think that 5.7 will/would be only to make the bed
for 7.0, mostly introducing E_DEPRECATEDs and maybe a handfull of small
features.
I think that there is no reason to give up our current release policy and
roadmap, and bet everything on PHP7, we don't lose anything with keeping
5.7.
My main concern with this is that it's php6 all over again. A PHP 7 where
everyone waits and pushes all their new stuff in their but nobody actually ever
releases because "one more feature" or they are too busy maintaining the old
series. I personally feel PHP7 will be stale and slowly die if we do a 5.7, or
who wants to even further support multiple branches with different APIs (didn't
we learn anything from PHP 6?).
(didn't
we learn anything from PHP 6?).
I did. And with opcache. Both with hypothetical deadlines based on
arbitrary random facts about the status or stability.
Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.
Let be realistic instead of yet again trying to achieve impossible goals,
or think we achieved them and release something we won't be able to change
for the next decade.
--001a1133979e094b370500b2c0a9
Content-Type: text/plain; charset=UTF-8(didn't
we learn anything from PHP 6?).
I did. And with opcache. Both with hypothetical deadlines based on
arbitrary random facts about the status or stability.Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.Let be realistic instead of yet again trying to achieve impossible goals,
or think we achieved them and release something we won't be able to change
for the next decade.
Let me summerize a few things that have come up:
(1) phpng doesn't justify PHP7
It does. It's a complete new engine. It has performance improvements. Where
do you draw the line of what justifies a PHP 7? It's a major BC break and we
needd a major version for it
(2) We can't get it stable.
That's to be debated. The question is, with what we have now can we stabelize
that?
Modern release process try to minimize the delta between versions as much as
possible. The only reason why we do a 7 instead of 5.7 is becuse we have a BC
break to serve. In fact we do want to serve it as soon as possible. That we
ensure people have time to move their products over. Most importantly we keep
have to keep the divergance between branches as small as possible to make moving
to new versions easier for our users and easier for us to maintain all the open
branches (which are too many already).
So the only question remains: Can we do PHP 7 with exactly ONLY the features we
have in the next 12 months?
--001a1133979e094b370500b2c0a9
Content-Type: text/plain; charset=UTF-8(didn't
we learn anything from PHP 6?).
I did. And with opcache. Both with hypothetical deadlines based on
arbitrary random facts about the status or stability.Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.Let be realistic instead of yet again trying to achieve impossible goals,
or think we achieved them and release something we won't be able to change
for the next decade.Let me summerize a few things that have come up:
(1) phpng doesn't justify PHP7
It does. It's a complete new engine. It has performance improvements. Where
do you draw the line of what justifies a PHP 7? It's a major BC break and we
needd a major version for it
No it does not. Even if it would do, that's not something I can live
with in the next 10 years. As I repeatedly said, with explanations
why.
--
Pierre
@pierrejoye | http://www.libgd.org
<snip> >> Let me summerize a few things that have come up: >> >> (1) phpng doesn't justify PHP7 >> It does. It's a complete new engine. It has performance improvements. Where >> do you draw the line of what justifies a PHP 7? It's a major BC break and we >> needd a major version for it > > > No it does not. Even if it would do, that's not something I can live > with in the next 10 years. As I repeatedly said, with explanations > why.
Just a heretical question from someone who has no clue about PHP core:
What speaks against having PHP 8 one or two years after PHP 7?
I like the idea of
-
having PHP 5.7 introducing deprecation warnings without additional
features (and perhaps some cleanings regarding the spec?) -
full concentration on PHP 7 regarding phpng (including AST & co) and
cleanings according to the spec. -
PHP 8 with other improvements that are currently planed for PHP 7.
(Perhaps it's even possible to introduce most deprecation warnings of
planned changes for 8 in 7 and 5.7.)
Regarding adoption: Agile teams/projects are able to follow the path
from 5.6 to 5.7 (if needed) up to 7 and 8. Slow teams/projects can
migrate from 5.6 to 5.7 "easily" and later to 8. Adoption to PHP 7 would
not be a KPI of the PHP project.
Regarding branch maintenance: Support for 5.7 could be extended and for
7 could be shortened if announced early enough (latest at GA of 7.0).
Regarding PHP project's project management: That would be release early,
release often. Of course, extensions need to be changed twice for PHP 7
and 8 - but the amount of changes should be almost the same.
A side note regarding the spec: I would not waste time to write/discuss
a formal spec that describes all oddities of 5.6/7 or force 5.6/7 to
follow a spec too much. The perspective of the spec is PHP 7 that is the
first version where compliance to the spec is needed. (Probably Facebook
has other plans. But I think one year to get it right on both sides -
the spec and the implementation - is totally ok.)
Regards
Thomas
Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.
IMHO, that'll depend on which feature will be added/changed/refactored
for 7. I might have missed that discussion, but so far I haven't seen a
wishlist or anything similar appear.
It might be time for everyone to sum up what they'd like to see happen
for 7, so it can be discussed and we have some idea of how big the task
of developing 7 is. There's no point discussing timeframes if you don't
know what needs to be done within the timeframe.
(Again : maybe I missed that 7 feature thread. In that case, never mind
;-) )
Wim
Wim Godden wrote:
Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.IMHO, that'll depend on which feature will be added/changed/refactored
for 7. I might have missed that discussion, but so far I haven't seen a
wishlist or anything similar appear.
There is https://wiki.php.net/ideas/php6 (which might be renamed, BTW).
--
Christoph M. Becker
Christoph Becker in php.internals (Sat, 16 Aug 2014 01:33:28 +0200):
Wim Godden wrote:
Here we have two issues, whether or not we need a 5.x to prepare 7 and if
one year Dev time is enough.IMHO, that'll depend on which feature will be added/changed/refactored
for 7. I might have missed that discussion, but so far I haven't seen a
wishlist or anything similar appear.There is https://wiki.php.net/ideas/php6 (which might be renamed, BTW).
And most of these things have to be added to PHP 7 before the feature
freeze. 'one year Dev time' might actually be only 10 months. Feature
freeze for 5.6.0 was mid June...
Jan
Christoph Becker in php.internals (Sat, 16 Aug 2014 01:33:28 +0200):
Wim Godden wrote:
Here we have two issues, whether or not we need a 5.x to prepare 7
and if
one year Dev time is enough.IMHO, that'll depend on which feature will be added/changed/refactored
for 7. I might have missed that discussion, but so far I haven't seen a
wishlist or anything similar appear.There is https://wiki.php.net/ideas/php6 (which might be renamed, BTW).
And most of these things have to be added to PHP 7 before the feature
freeze. 'one year Dev time' might actually be only 10 months. Feature
freeze for 5.6.0 was mid June...
More 7-8 months...
Am 16.08.2014 um 00:19 schrieb David Soria Parra:
My main concern with this is that it's php6 all over again.
That is my fear, too.
Am 15.08.2014 um 02:48 schrieb Andrea Faulds:
As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add
deprecation warnings and such to help people prepare for 7.
If the only changes that PHP 5.7 introduces (as compared to PHP 5.6) are
deprecation warnings for features removed in PHP 7 then I am all for
having PHP 5.7.
With regard to the scope of PHP 7, I think it would be great to limit
ourselves to "infrastructure" improvements (new executor from PHPNG,
AST-based compiler (plus userland extension that provides access to
the AST) from Nikita) and cleanup (removal of deprecated features).
This cleaned up platform would be a great foundation for introducing new
features in PHP 7.1.
With regard to the scope of PHP 7, I think it would be great to limit
ourselves to "infrastructure" improvements (new executor from PHPNG,
AST-based compiler (plus userland extension that provides access to
the AST) from Nikita) and cleanup (removal of deprecated features).
This cleaned up platform would be a great foundation for introducing new
features in PHP 7.1.
I’m not sure that’s a good idea. Certain new features would require breaking backwards-compatibility, which we can’t do in minor releases.
Andrea Faulds
http://ajf.me/
Hi all,
I’ve kept putting this off, but given the current “move phpng to master”
vote, I really can’t delay this any longer.It looks like PHP 7 is going to happen and phpng will be the base of that.
While we could move straight to PHP 7 after the release of PHP 5.6, I think
there is some merit in having one more 5.x release, namely 5.7, which would
follow our usual release process and come out next year.PHP 7, as a major release, is likely to take much longer than a usual
minor release. While some people might think one year is realistic, I
highly doubt that, as I suspect phpng will not be the only new feature PHP
7 will contain. Major releases come with major changes, and I suspect some
others will crop up, and these might delay the release. Because it will
probably take two to three years, having a minor release in the meantime
means userland developers won’t be starved of new features which don’t need
to be in a major release and could be in a minor.Another point is that PHP 7 is probably going to break
backwards-compatibility more significantly than minors would. For starters,
phpng will break extension compatibility, and new proposals are likely to
break userland compatibility as well. By making 5.7 happen, developers will
have more time to switch to PHP 7 and can keep their existing codebases for
longer.As PHP 7 may break backwards-compatibility, 5.7 gives us a chance to add
deprecation warnings and such to help people prepare for 7.Finally, it is a fallback. If we do end up targeting 7 to come out next
year, then if serious issues cause delays to 7, we will have a less
ambitious and working new release to fall back on.I should clarify that I don’t wish to delay phpng at all, I am very much
in favour of it and excited about it, nor do I expect this to delay it. We
can simply work on two releases at once: PHP 7, an ambitious BC-breaking
release to come out later, and PHP 5.7, a safe, non-breaking release that
will come out next year with the usual schedule.
+1
Having 5.7 would be nicer for users and developers.
Let's have 5.7 and master branch for PHP7 now.
I would like to have +1 year dev time for PHP7. However, it may be good
idea to release
5.7 and 7.0 at the same time. I suppose big changes may be implemented in
7.x.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net