Hi people.
Ferenc and I, actual RM of 5.5 and 5.6 , were discussing the calendar today
on IRC.
Let's start with facts :
- We release new PHP versions (major or minor) on summer. Usually, if we
can have it end of June, it is good. - We may delay that, 5.6 got released end of summer : in september. It is
bad, but acceptable. - We always have, from our release process, 2 active versions at the same
time + 1 sec fix version. Not more, not less.
If we release during summer, that means we need to prepare everything
around Christmas.
Tip : Christmax is approaching :-)
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at least
one year later.
If not : we'll happen having 3 active versions (5.6 , 5.7 and 7.0) and one
sec-fix only (5.5) , this is something we don't want , because we have
the feeling that it is too much pain to maintain so many versions alive.
-
If we go for 7.0 :
I wouldn't mind delaying its release to November(2015) if needed, its a
major, extra care should be taken. However, not later : our release process
status for 2 years of active life , if 7.0 were to be released in 2016,
then we'd have 5.5 lasting for much more than 2 years active. -
If we go for 5.7 :
We could release it this summer (2015) , but that would mean that 7.0
wouldn't come before summer 2016.
Releasing a 5.7 will lean the release cycle curve, but it is not mandatory,
that should be debatted.
Decisions should be taken now : aka in 2014.
Taking decisions later than this will lead to a rush in release process,
wich is very bug/error prone, and should be prevented.
Thank you.
Julien.Pauli
- If we go for 7.0 :
I wouldn't mind delaying its release to November(2015) if needed, its a
major, extra care should be taken. However, not later : our release process
status for 2 years of active life , if 7.0 were to be released in 2016,
then we'd have 5.5 lasting for much more than 2 years active.
Hey Julien,
I thought this was already pretty much decided in the 7.0 timeline
RFC. I don't see your vote on there, did you miss it?
https://wiki.php.net/rfc/php7timeline
The goal of mid-October (subject to quality) caters for your November
delay too. Since the vote was so positive, I think we should stick to
this.
Hi people.
Ferenc and I, actual RM of 5.5 and 5.6 , were discussing the calendar today
on IRC.Let's start with facts :
- We release new PHP versions (major or minor) on summer. Usually, if we
can have it end of June, it is good.- We may delay that, 5.6 got released end of summer : in september. It is
bad, but acceptable.
Lies, it was released at the end of August. :P
- We always have, from our release process, 2 active versions at the same
time + 1 sec fix version. Not more, not less.If we release during summer, that means we need to prepare everything
around Christmas.
Tip : Christmax is approaching :-)So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at least
one year later.
If not : we'll happen having 3 active versions (5.6 , 5.7 and 7.0) and one
sec-fix only (5.5) , this is something we don't want , because we have
the feeling that it is too much pain to maintain so many versions alive.
If we go for 7.0 :
I wouldn't mind delaying its release to November(2015) if needed, its a
major, extra care should be taken. However, not later : our release process
status for 2 years of active life , if 7.0 were to be released in 2016,
then we'd have 5.5 lasting for much more than 2 years active.If we go for 5.7 :
We could release it this summer (2015) , but that would mean that 7.0
wouldn't come before summer 2016.
Releasing a 5.7 will lean the release cycle curve, but it is not mandatory,
that should be debatted.Decisions should be taken now : aka in 2014.
Taking decisions later than this will lead to a rush in release process,
wich is very bug/error prone, and should be prevented.Thank you.
Julien.Pauli
it would be also possible to release 5.7 and 7.0 in parallel, and I know
that some people were against this, as this would mean less effort going
into 7.0, but to be honest, I think that it would only mean that instead of
continuing to accept small self contained features to 5.6.x (which we
already have a couple and people are we are still have a bunch more
requested/worked on already), we would turn 5.5/5.6 into mostly bugfix
status and push those small features into 5.7 instead.
Given the past trends about the penetration of new major(ish) php versions,
I'm fairly sure that when 5.6 gets EOLed, there will be plenty of
people/projects who will not be ready to migrate to PHP7 yet, so I think
that one way or another, 5.6 won't be the last minor version in the PHP 5
family.
If we can agree on that, I think it would make sense to have an 5.7
released a bit before or together with 7.0, which can be used as a stepping
stone for migrating 7.0: we could make sure that anything which will be
changed/removed in 7.0 is properly deprecated in 5.7, so you will do two
smaller steps instead of one big one.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.
We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#vote
So that means no 5.7.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#voteSo that means no 5.7.
This rfc was specific to php7, and while you are right that with that we do
have an approved timelime for php7, but this doesn't say anything about 5.7
(and as far as I'm concerned, it was an intentional choice from Zeev not
just something he forgot to include).
Maybe it would be worthwile for you to repeat your arguments or simply link
them, as I do remember that you are supporting the idea of not having any
other release minor release until php7 is out of the door so the
development efforts are not fragmented (which as I mentioned in my previous
mail I feell it would be only a shift from 5.6.x to 5.7.0 and not
fragmanting the php7 development, but you seem to disagree).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#voteSo that means no 5.7.
This rfc was specific to php7, and while you are right that with that we
do have an approved timelime for php7, but this doesn't say anything about
5.7 (and as far as I'm concerned, it was an intentional choice from Zeev
not just something he forgot to include).
Maybe it would be worthwile for you to repeat your arguments or simply
link them, as I do remember that you are supporting the idea of not having
any other release minor release until php7 is out of the door so the
development efforts are not fragmented (which as I mentioned in my previous
mail I feell it would be only a shift from 5.6.x to 5.7.0 and not
fragmanting the php7 development, but you seem to disagree).
True : We then have agreed for the PHP7 planning, by RFC voting.
BUT, we still haven't argued about a possible 5.7 in the next time as 7.0
(and then , about the status/lifetime of 5.6).
Julien.P
So the main question is : What version will we release next year
?Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0
at least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#voteSo that means no 5.7.
This rfc was specific to php7, and while you are right that with that
we do have an approved timelime for php7, but this doesn't say
anything about 5.7 (and as far as I'm concerned, it was an intentional
choice from Zeev not just something he forgot to include).Maybe it would be worthwile for you to repeat your arguments or simply
link them, as I do remember that you are supporting the idea of not
having any other release minor release until php7 is out of the door
so the development efforts are not fragmented (which as I mentioned in
my previous mail I feell it would be only a shift from 5.6.x to 5.7.0
and not fragmanting the php7 development, but you seem to disagree).
Yes, I disagree. It's a time thing. Let's all work on one thing instead
of two. Clearly you must see that there is not enough bandwidth? It
will also prevent people from "oh we can get this into 5.7" nonsense.
It's not helpful, and it is fragmenting development.
cheers,
Derick
Yes, I disagree. It's a time thing. Let's all work on one thing instead
of two. Clearly you must see that there is not enough bandwidth? It
will also prevent people from "oh we can get this into 5.7" nonsense.
It's not helpful, and it is fragmenting development.
I'm just as cognisant of our time constraints as you are, but I still
think this can work if there's a clear, written expectation (say via
RFC) that 5.7 is for migration related changes only, and should not
include new feature work. If we can keep this as "5.6 + some
deprecation warnings", I believe that can reduce the QA/development
load enough to make delivering it and 7.0 possible next year.
Adam, who apparently put his optimistic pants on this morning.
-----Original Message-----
From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Monday, December 15, 2014 8:12 PM
To: Derick Rethans
Cc: PHP Internals
Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?Yes, I disagree. It's a time thing. Let's all work on one thing
instead of two. Clearly you must see that there is not enough
bandwidth? It will also prevent people from "oh we can get this into
5.7"
nonsense.
It's not helpful, and it is fragmenting development.I'm just as cognisant of our time constraints as you are, but I still
think this
can work if there's a clear, written expectation (say via
RFC) that 5.7 is for migration related changes only, and should not
include
new feature work. If we can keep this as "5.6 + some deprecation
warnings",
I believe that can reduce the QA/development load enough to make
delivering it and 7.0 possible next year.
5.6 + deprecation warnings might be something we can even consider for the
5.6.x tree, as we get closer to release 7.0. I think if we do that, it
becomes more interesting since the likelihood of people upgrading to such a
version go higher (psychologically, moving to 5.7 is a much bigger deal than
upgrading from 5.6.10 to 5.6.11).
Zeev
-----Original Message-----
From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Monday, December 15, 2014 8:12 PM
To: Derick Rethans
Cc: PHP Internals
Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?Yes, I disagree. It's a time thing. Let's all work on one thing
instead of two. Clearly you must see that there is not enough
bandwidth? It will also prevent people from "oh we can get this into
5.7"
nonsense.
It's not helpful, and it is fragmenting development.I'm just as cognisant of our time constraints as you are, but I still
think this
can work if there's a clear, written expectation (say via
RFC) that 5.7 is for migration related changes only, and should not
include
new feature work. If we can keep this as "5.6 + some deprecation
warnings",
I believe that can reduce the QA/development load enough to make
delivering it and 7.0 possible next year.5.6 + deprecation warnings might be something we can even consider for the
5.6.x tree, as we get closer to release 7.0. I think if we do that, it
becomes more interesting since the likelihood of people upgrading to such a
version go higher (psychologically, moving to 5.7 is a much bigger deal
than
upgrading from 5.6.10 to 5.6.11).
there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .
And LTS versions can be ring fenced at 5.6 ... with just functional fixes.
Perhaps what is needed is a tool which does identify the problems in 5.X
code that need to be addressed in order to run clean in PHP7. Rather
than encumbering PHP7 with E_STRICT type warning/error code, PHP5.7
would be a test environment to replace that functionality. Once code
runs clean then one knows that it can be moved over? Style changes like
the 'incorrect ternary '?' associativity' function would be highlighted
so that BC problems are not silently changed. A properly documented
migration tool rather than a production release as I would not expect to
use PHP5.7 in a production environment!
--
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
there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)
So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see
them on 7.0 as soon as possible.
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .
New features in 5.6 should be rejected and added to 7.0 to give users
more reasons to upgrade.
johannes
Hi,
there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see
them on 7.0 as soon as possible.
Honestly, I don’t think Debian will switch to PHP 7, nor will any other distro, because it’s a new major version and it breaks things. php will probably continue to be PHP 5, they’ll add php7, prolong 5.6 or 5.7’s life for five years, and eventually switch php over to 7.
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .New features in 5.6 should be rejected and added to 7.0 to give users
more reasons to upgrade.
I agree on this one.
Thanks.
Andrea Faulds
http://ajf.me/
On Tue, Dec 16, 2014 at 12:32 AM, Johannes Schlüter johannes@schlueters.de
wrote:
there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see
them on 7.0 as soon as possible.
I don't think that they would pick up 7.0 instantly, even if there is no
5.7 but let's assume that you are right and having 5.7 will delay the 7.0
adoption by one year(as having 5.7 will prolong the support for the 5.x
series by a year), I still think it would worth having a version to make
the bed for 7.0.
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .New features in 5.6 should be rejected and added to 7.0 to give users
more reasons to upgrade.
That's also an option, and now that we have a timeline for 7.0 it is a bit
easier to convince people to wait for 7.0.
Based on the numerous arguments that I had on the mailing list and on irc,
it seems that I'm in the minority with my interpretation of
https://wiki.php.net/rfc/releaseprocess:
internals@lists.php.net/msg71665.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg71665.html
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#vote
I hate to say that but if we stick to rules, this rfc and its result are
totally invalid and should be canceled.
So that means no 5.7.
No.
cheers,
Derick--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#voteI hate to say that but if we stick to rules, this rfc and its result are
totally invalid and should be canceled.
What a bonkers statement. Just because you don't agree it's not
"totally invalid". I think 34 vs 2 is a pretty solid argument for
sticking to it.
cheers,
Derick
So the main question is : What version will we release next year ?
Will we have a PHP 5.7, or jump directly to a 7.0 ?
Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
least one year later.We have accepted the timeline for 7, so we need to stick to that:
https://wiki.php.net/rfc/php7timeline#voteI hate to say that but if we stick to rules, this rfc and its result are
totally invalid and should be canceled.What a bonkers statement. Just because you don't agree it's not
"totally invalid". I think 34 vs 2 is a pretty solid argument for
sticking to it.
Aller php7 related RFCs from there are invalid if we stick to the rules.
The author asked to respect rules while systematically breaking them. And
that's my point here.
People voting massively yes because " oh it will not happen if we don't say
yes now" is only bad. For that last one, even the author admit that we may
not make it as described.
I may propose a counter rfc or just for 5.7, did not make my mind yet. Why
should I make a php7 more complete rfc? Because we agreed to make one
together to propose actual choices. I was respectful enough to wait on the
other author until he was ready. Nice move.
So please, before you go up your horse telling me that my arguments are
bad, get your facts straight, thanks.
Cheers,
Pierre
Pierre Joye wrote on 15/12/2014 17:39:
I hate to say that but if we stick to rules, this rfc and its result are
totally invalid and should be canceled.
What a bonkers statement. Just because you don't agree it's not
"totally invalid". I think 34 vs 2 is a pretty solid argument for
sticking to it.
Aller php7 related RFCs from there are invalid if we stick to the rules.
The author asked to respect rules while systematically breaking them. And
that's my point here.
Can you succinctly, without any personal attacks, explain which rules
this RFC broke?
Thanks,
Rowan Collins
[IMSoP]
Just because we are releasing PHP 7.0 next year (well, according to
our timeline anyway) that doesn't mean we can't release a 5.7.
The advantage of PHP 5.7 is clear to me at least: it would extend
support for the 5.X series by another year, get bug fixes, and contain
E_DEPRECATED warnings and other things that should make migrating to
PHP 7.0 easier. I personally do not suggest adding any features in PHP
5.7.
And to reiterate this in case someone has missed it: we have already
voted on and accepted an RFC which targets PHP 5.7:
https://wiki.php.net/rfc/switch.default.multiple
Just because we are releasing PHP 7.0 next year (well, according to
our timeline anyway) that doesn't mean we can't release a 5.7.
Agreed.
I have to apologise here — I've had a draft RFC half-written for over
a week at this point that would lay out a timeline and scope for PHP
5.7 (and think I mentioned it on IRC, so I'm sorry if I forestalled
someone else doing the same), and haven't had time to finish it and
send it due to travelling.
The advantage of PHP 5.7 is clear to me at least: it would extend
support for the 5.X series by another year, get bug fixes, and contain
E_DEPRECATEDwarnings and other things that should make migrating to
PHP 7.0 easier. I personally do not suggest adding any features in PHP
5.7.
I completely agree: 5.7 should happen, and should include deprecation
warnings where appropriate, reserve any keywords that will be reserved
in PHP 7, and generally make it easier to maintain code that works on
both versions.
In terms of timeline: I think we could (and should) release this in
August, assuming we stick to the limited scope above. We could really
branch any time from PHP-5.6. We'll know what new warnings need to be
in 5.7 by mid-March, per the PHP 7 timeline, and could then start the
alpha/beta cycle there: in general, less testing should be required
than normal compared to the last few versions due to the scope, and
4-5 months would be plenty to get through testing, even given that
most people would be (understandably) focused on PHP 7.
Adam
So the main question is : What version will we release next year ?
We've already answered that question, as per the PHP 7 timeline RFC, we're
aiming to release PHP 7 in 2015. Sure, given the aggressive timeline
there's the possibility that we won't be able to make it on time, but that's
our goal.
If not : we'll happen having 3 active versions (5.6 , 5.7 and 7.0) and one
sec-
fix only (5.5) , this is something we don't want , because we have the
feeling that it is too much pain to maintain so many versions alive.
It's worse than that. Since the PHP 7 timeline was already approved and
must be a working assumption, introducing a 1yr delay for 5.7 is out of the
question. That means that working on PHP 5.7 would require us to work on
two upcoming content releases (with new features and substantial changes)
simultaneously, which IIRC is both unprecedented and a bad idea given our
limited resources. In my opinion, we should definitely focus all of our
resources and bandwidth on getting 7.0 out the door. 7.0 is strategic. 5.7
is tactical.
- If we go for 7.0 :
I wouldn't mind delaying its release to November(2015) if needed, its a
major, extra care should be taken. However, not later : our release
process
status for 2 years of active life , if 7.0 were to be released in 2016,
then we'd
have 5.5 lasting for much more than 2 years active.
Per the timeline RFC we're already looking at a mid-October timeframe for
GA, but it actually does make provisions for delaying it - high quality is
more important than the timeline - although we should absolutely strive to
meet the milestones in the RFC.
- If we go for 5.7 :
We could release it this summer (2015) , but that would mean that 7.0
wouldn't come before summer 2016.
Releasing a 5.7 will lean the release cycle curve, but it is not
mandatory, that
should be debatted.
A 5.7 that pushes 7.0 into Summer 2016 is IMHO a strategic mistake, but
regardless I think the discussion is moot. We've already decided we're
aiming for a 2015 PHP 7.0 release, and should stick to that plan.
Zeev
- If we go for 5.7 :
We could release it this summer (2015) , but that would mean that 7.0
wouldn't come before summer 2016.
Releasing a 5.7 will lean the release cycle curve, but it is not
mandatory, that
should be debatted.A 5.7 that pushes 7.0 into Summer 2016 is IMHO a strategic mistake, but
regardless I think the discussion is moot. We've already decided we're
aiming for a 2015 PHP 7.0 release, and should stick to that plan.
Assuming we do a PHP 5.7 as I outlined previously, it shouldn't take
anything more than a few hours here and there by a release manager and
a tiny bit of extra work for a few RFC authors. It's just normal bug
fixes, version bump, and compatibility stuff for PHP 7. As long as we
keep features out of PHP 5.7 it should not delay a PHP 7 release.
-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On
Behalf Of Levi Morrison
Sent: Friday, December 12, 2014 10:00 PM
To: Zeev Suraski
Cc: Julien Pauli; PHP Internals
Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
- If we go for 5.7 :
We could release it this summer (2015) , but that would mean that 7.0
wouldn't come before summer 2016.
Releasing a 5.7 will lean the release cycle curve, but it is not
mandatory, that should be debatted.A 5.7 that pushes 7.0 into Summer 2016 is IMHO a strategic mistake,
but regardless I think the discussion is moot. We've already decided
we're aiming for a 2015 PHP 7.0 release, and should stick to that plan.Assuming we do a PHP 5.7 as I outlined previously, it shouldn't take
anything
more than a few hours here and there by a release manager and a tiny bit
of
extra work for a few RFC authors. It's just normal bug fixes, version
bump,
and compatibility stuff for PHP 7. As long as we keep features out of PHP
5.7
it should not delay a PHP 7 release.
Levi, Andrea, Adam, and others that suggested we can do 5.7 in parallel
while sticking to the 7.0 timeline:
-
I was replying to Julien. Julien said in at least 3 different places in
his email that if we do 5.7, we'll clearly not be doing 7.0 in 2015 and it
will clearly mean delaying 7.0 by a year. If you disagree, you should be
replying to and discussing with him, not me. Perhaps Julien and you have
different ideas about what 5.7 is; Even though it's not explicitly
mentioned in his email, it certainly sounds that in his mind, 5.7 is just as
much of a release as 5.6 or 5.5 were. -
My position about 5.7 that's minimally different from 5.6 and just
'helps migration', is that it's practically useless. Users won't go through
the headache of hopping through two versions, for some supposed unknown
benefits. PHP 7 breakage is going to be fairly localized to specific
areas - not so much the engine changes which barely breaks anything. So if
5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right
places, etc.) - migrating to it would essentially be as painful (or
painless) as migrating to 7.0. In other words, no benefits to doing this
extra step from the point of view of most users. -
Last (and probably least) - a 5.7 that breaks compatibility is
inconsistent with our version strategy, that suggests 5.7 should be fully
compatible with 5.6.
All in all, whether it's a feature release or an empty shell with just 7.0's
compatibility breakages, I don't see how 5.7 makes sense.
Zeev
Levi, Andrea, Adam, and others that suggested we can do 5.7 in parallel
while sticking to the 7.0 timeline:
- I was replying to Julien. Julien said in at least 3 different places
in
his email that if we do 5.7, we'll clearly not be doing 7.0 in 2015 and it
will clearly mean delaying 7.0 by a year. If you disagree, you should be
replying to and discussing with him, not me.
This is a public mailing list, for open discussions. You replied to
arguments, so we do. It brings pros and cons to a debate you delibatery
killed with your incomplete rfc, breaking rules again while being at it.
Perhaps Julien and you have
different ideas about what 5.7 is; Even though it's not explicitly
mentioned in his email, it certainly sounds that in his mind, 5.7 is just
as
much of a release as 5.6 or 5.5 were.
Not necessarily and this is what we are discussing here.
- Last (and probably least) - a 5.7 that breaks compatibility is
inconsistent with our version strategy, that suggests 5.7 should be fully
compatible with 5.6.
It won't if we do it right.
- Last (and probably least) - a 5.7 that breaks compatibility is
inconsistent with our version strategy, that suggests 5.7 should be fully
compatible with 5.6.
Whoa — I'm not talking about breaking compatibility. I'm talking about
generating deprecation warnings on things we know are going to break
in PHP 7.
Travelling backwards a point:
- My position about 5.7 that's minimally different from 5.6 and just
'helps migration', is that it's practically useless. Users won't go through
the headache of hopping through two versions, for some supposed unknown
benefits. PHP 7 breakage is going to be fairly localized to specific
areas - not so much the engine changes which barely breaks anything. So if
5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right
places, etc.) - migrating to it would essentially be as painful (or
painless) as migrating to 7.0. In other words, no benefits to doing this
extra step from the point of view of most users.
As I said, 5.7 wouldn't break anything, to my mind. The point is to
provide a way for users to get a heads up on what things they need to
be looking into to either migrate to PHP 7, or have a single code base
that runs on both PHP 5 and 7, depending on their needs.
The Python experience suggests that both of these cases need to be
supported, and well. Why wouldn't we — the people best placed to do so
— provide the tooling to do that as part of the runtime?
The strawman version of your position seems to be that users are going
to just migrate to PHP 7 en masse, and that they'll be happy with
their code breaking to tell them what to fix. I'm not sure there's any
history in PHP or other languages that suggests that's really what
will happen, and I think we're doing our users a disservice if we
don't make the path to having a mixed 5/7 code base as easy as
possible.
Adam
-----Original Message-----
From: Adam Harvey [mailto:adam@adamharvey.name]
Sent: Monday, December 15, 2014 8:06 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
- Last (and probably least) - a 5.7 that breaks compatibility is
inconsistent with our version strategy, that suggests 5.7 should be
fully compatible with 5.6.Whoa — I'm not talking about breaking compatibility. I'm talking about
generating deprecation warnings on things we know are going to break in
PHP 7.
Ok, that's borderline breaking compatibility if we want people to actually
notice it (otherwise it'd be hidden by default settings). But I admit
that's nitpicking, withdrawn :)
Anyway, the #1 (literally) in my email was that the OP (Julien) clearly had
a different 5.7 in mind than what you're describing.
As I said, 5.7 wouldn't break anything, to my mind. The point is to
provide a
way for users to get a heads up on what things they need to be looking
into
to either migrate to PHP 7, or have a single code base that runs on both
PHP
5 and 7, depending on their needs.The Python experience suggests that both of these cases need to be
supported, and well. Why wouldn't we — the people best placed to do so —
provide the tooling to do that as part of the runtime?The strawman version of your position seems to be that users are going to
just migrate to PHP 7 en masse, and that they'll be happy with their code
breaking to tell them what to fix. I'm not sure there's any history in PHP
or
other languages that suggests that's really what will happen, and I think
we're doing our users a disservice if we don't make the path to having a
mixed 5/7 code base as easy as possible.
I don't think people will migrate to PHP 7 en-masse. Our past experience
with major versions (and even minor ones) doesn't support this thesis -
it'll take time. But I do think that people who decide it's worth their
while to migrate, will migrate and take the pain that it takes to make the
necessary changes. The extra pain associated with migrating to an interim
version - that does nothing but spew warnings in the right places -and
obviously doesn't have any of the other features of 7 - doesn't seem to be a
worthwhile experience for most users.
Zeev
Am 15.12.2014 20:43 schrieb "Zeev Suraski" zeev@zend.com:
The extra pain associated with migrating to an interim
version - that does nothing but spew warnings in the right places -and
obviously doesn't have any of the other features of 7 - doesn't seem to
be a
worthwhile experience for most users.
I dont't know about "most users", I can only speak for myself from our
small shop (in the big scheme of things...) production and development
experience. I compile PHP myself for our setup, and have a nice compilation
and deployment environment where I can easily throw new versions separately
onto developer hosts and production hosts. We made our codebase
E_STRICT|E_DEPRECATED-clean on the transition from 5.3 to 5.4, meanwhile
migrated to 5.5, and soon to 5.6, with almost no pain, by first running new
versions on developer machines and then on one of several production
servers, where possibly issues are visible pretty fast.
Now with PHP 7 promising potential for incompatibilities in a lot more
areas, it would be, to us, a really useful option to have a 5.7 that is
operationally fully compatible with 5.6 with added E_DEPRECATED for things
bound to break. With that we could A) rub the developers' noses in the
relevant deprecation messages for a while, and run one or more rounds of
one-of-the-production -server tests, gathering more deprecation messages
there without fear of user visible effects.
I cannot judge how much effort such a 5.7 would be for you as developers,
and for the release managers, but I definitely would appreciate the effort,
and I'm 100% sure that it would speed up our eventual adoption of PHP 7 by
at least half a year, because the process would be much less risky.
best regards
Patrick
Patrick Schaaf in php.internals (Mon, 15 Dec 2014 21:36:33 +0100):
Now with PHP 7 promising potential for incompatibilities in a lot more
areas, it would be, to us, a really useful option to have a 5.7 that is
operationally fully compatible with 5.6 with addedE_DEPRECATEDfor things
bound to break. With that we could A) rub the developers' noses in the
relevant deprecation messages for a while, and run one or more rounds of
one-of-the-production -server tests, gathering more deprecation messages
there without fear of user visible effects.
I fully agree with you. Not only for migrating our own code a version
with deprecation warnings would be helpful. But I think that such a
version would also be a big help for migrating frameworks like Drupal
ans Wordpress. If you want a move to PHP7 you have to make their
migration path smooth.
Jan
Hi!
If not : we'll happen having 3 active versions (5.6 , 5.7 and 7.0) and one
sec-
fix only (5.5) , this is something we don't want , because we have the
feeling that it is too much pain to maintain so many versions alive.It's worse than that. Since the PHP 7 timeline was already approved and
must be a working assumption, introducing a 1yr delay for 5.7 is out of the
question. That means that working on PHP 5.7 would require us to work on
two upcoming content releases (with new features and substantial changes)
simultaneously, which IIRC is both unprecedented and a bad idea given our
limited resources. In my opinion, we should definitely focus all of our
resources and bandwidth on getting 7.0 out the door. 7.0 is strategic. 5.7
is tactical.
I must disagree: 5.7 would only be trivially different from 5.6 (deprecations), the effort involved is only as much as continuing to maintain 5.6, and we have to do that anyway. So there’s no problem with working on both.
Thanks!
Andrea Faulds
http://ajf.me/
I must disagree: 5.7 would only be trivially different from 5.6 (deprecations), the effort involved is only as much as continuing to maintain 5.6, and we have to do that anyway. So there’s no problem with working on both.
I have to say I very much agree with this. I see 5.7 as a featureless
stepping stone to aid 7.0 adoption. Very much in line with what Ferenc
suggested earlier on.