See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?
BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.html
Jan
Well, August 2015 has already passed.
I guess 5.6 will be extended till Dec 2016 and security support till Dec
But that's for the community to decide.
Kaplan
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
-----Original Message-----
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
Sent: Sunday, December 06, 2015 2:15 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP 5.6 life cycleSee http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on
28 Aug 2016? Or will we be postponing this a couple of months?
I think you're off by one here, no?
BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.html
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).
PHP 4 was maintained for 4+ years after PHP 5.0 was released (5.0 release
July 2004, PHP 4 support ended 8/8/08). Not saying that we need to do the
same for 5, but one year upgrade cycle for everyone on 5.x doesn't sound
reasonable. I don't have a firm opinion on 'active support' vs. 'security
only' - I think the latter much more closely defines what people truly
care about in terms of whether they feel comfortable having the version
still deployed or not.
At the very least I think we should give 5.6 24 months of lifetime from
PHP 7.0's release date (i.e. take it until Dec 2017), but I think we
should also consider either extending it even further, or at least paying
attention to the situation on the ground in terms of PHP 5's popularity as
we get closer to that EOL date. Personally I'm leaning towards having a
firm date further down the road than a 'flexible' one, so that we give
people a clear and reasonable timeline to upgrade - without risking that
they "won't take us seriously" and assume we'd delay the EOL.
Zeev
Zeev Suraski in php.internals (Sun, 6 Dec 2015 14:38:10 +0200):
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).
There is a reason to treat it differently: extension support. Upgrading
the core and core extensions is relatively painless. Many popular
extensions are rapidly moving towards PHP7 support.
But there must be thousands of extensions out there, that we have no
knowledge of. For people that have already done a port to PHP7 the next
one is relatively simple. But porting your first one has a steep learning
curve.
Jan
-----Original Message-----
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
Sent: Sunday, December 06, 2015 3:21 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.6 life cycleZeev Suraski in php.internals (Sun, 6 Dec 2015 14:38:10 +0200):
IMHO, I think we need to look at the 5.6 lifecycle very differently
from how we look at 5.5 and earlier. This is really the 5.x lifecycle
as it's the last version that's relatively completely painless to
upgrade to from 5.x (especially 5.3 and later).But there must be thousands of extensions out there, that we have no
knowledge of. For people that have already done a port to PHP7 the next
one is relatively simple. But porting your first one has a steep
learning curve.
That's another good point I didn't think about.
Zeev
Zeev Suraski in php.internals (Sun, 6 Dec 2015 15:24:02 +0200):
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
But there must be thousands of extensions out there, that we have no
knowledge of. For people that have already done a port to PHP7 the next
one is relatively simple. But porting your first one has a steep
learning curve.That's another good point I didn't think about.
For extensions that also have Windows support there is an extra hurdle:
the dependencies have to be ported from VC11 to VC14. Your friend Pierre
will say: piece of cake. @Pierre: try to compile libgeoip. Unless VC14 SP1
does it better, there is a chance you will run into "fatal error C1026:
parser stack overflow, program too complex".
Jan
Le 06/12/2015 13:38, Zeev Suraski a écrit :
-----Original Message-----
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
Sent: Sunday, December 06, 2015 2:15 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP 5.6 life cycleSee http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on
28 Aug 2016? Or will we be postponing this a couple of months?
I think you're off by one here, no?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.html
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).PHP 4 was maintained for 4+ years after PHP 5.0 was released (5.0 release
July 2004, PHP 4 support ended 8/8/08). Not saying that we need to do the
same for 5, but one year upgrade cycle for everyone on 5.x doesn't sound
reasonable. I don't have a firm opinion on 'active support' vs. 'security
only' - I think the latter much more closely defines what people truly
care about in terms of whether they feel comfortable having the version
still deployed or not.At the very least I think we should give 5.6 24 months of lifetime from
PHP 7.0's release date (i.e. take it until Dec 2017), but I think we
should also consider either extending it even further, or at least paying
attention to the situation on the ground in terms of PHP 5's popularity as
we get closer to that EOL date. Personally I'm leaning towards having a
firm date further down the road than a 'flexible' one, so that we give
people a clear and reasonable timeline to upgrade - without risking that
they "won't take us seriously" and assume we'd delay the EOL.Zeev
What about modifying the rules to state that :
When a new major version (version N) is released, the latest minor
version of the previous major (N - 1) automatically gets one additional
year of active support, extending it to 3 years instead of 2. The
subsequent 'security fix only' period is maintained to one year.
Regards
François
Den 2015-12-06 kl. 17:39, skrev François Laupretre:
Le 06/12/2015 13:38, Zeev Suraski a écrit :
-----Original Message-----
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
Sent: Sunday, December 06, 2015 2:15 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP 5.6 life cycleSee http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on
28 Aug 2016? Or will we be postponing this a couple of months?
I think you're off by one here, no?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.html
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as
it's
the last version that's relatively completely painless to upgrade to
from
5.x (especially 5.3 and later).PHP 4 was maintained for 4+ years after PHP 5.0 was released (5.0
release
July 2004, PHP 4 support ended 8/8/08). Not saying that we need to
do the
same for 5, but one year upgrade cycle for everyone on 5.x doesn't sound
reasonable. I don't have a firm opinion on 'active support' vs.
'security
only' - I think the latter much more closely defines what people truly
care about in terms of whether they feel comfortable having the version
still deployed or not.At the very least I think we should give 5.6 24 months of lifetime from
PHP 7.0's release date (i.e. take it until Dec 2017), but I think we
should also consider either extending it even further, or at least
paying
attention to the situation on the ground in terms of PHP 5's
popularity as
we get closer to that EOL date. Personally I'm leaning towards having a
firm date further down the road than a 'flexible' one, so that we give
people a clear and reasonable timeline to upgrade - without risking that
they "won't take us seriously" and assume we'd delay the EOL.Zeev
What about modifying the rules to state that :
When a new major version (version N) is released, the latest minor
version of the previous major (N - 1) automatically gets one
additional year of active support, extending it to 3 years instead of
- The subsequent 'security fix only' period is maintained to one year.
Regards
François
Sounds like a good proposal to me. Starting point for a decision?
Would like to add that given 7.0 major uptake with ISP's coming next
year (at least in my region) it seems prudent to prolong 5.6 lifecycle a
little.
Regards //Björn
Am 06.12.2015 um 17:57 schrieb Björn Larsson:
Would like to add that given 7.0 major uptake with ISP's coming next
year (at least in my region) it seems prudent to prolong 5.6 lifecycle a
little.
I fear that extending support for PHP 5 will slow down adoption of
PHP 7.
Den 2015-12-06 kl. 18:05, skrev Sebastian Bergmann:
Am 06.12.2015 um 17:57 schrieb Björn Larsson:
Would like to add that given 7.0 major uptake with ISP's coming next
year (at least in my region) it seems prudent to prolong 5.6 lifecycle a
little.
I fear that extending support for PHP 5 will slow down adoption of
PHP 7.
Given the high performance boost with PHP 7 I don't think extended support
will delay for ISP's to offer PHP 7 for their customers. It's a very
good business
case to upgrade. I think it's more about migrating existing environment and
extension support that can delay things.
Regards //Björn
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 06/12/2015 13:38, Zeev Suraski a écrit :
IMHO, I think we need to look at the 5.6 lifecycle very differently
from how we look at 5.5 and earlier. This is really the 5.x
lifecycle as it's the last version that's relatively completely
painless to upgrade to from 5.x (especially 5.3 and later).
+1: last version 5 should probably be managed differently that other
5.x version.
PHP 4 was maintained for 4+ years after PHP 5.0 was released (5.0
release July 2004, PHP 4 support ended 8/8/08). Not saying that we
need to do the same for 5, but one year upgrade cycle for everyone
on 5.x doesn't sound reasonable. I don't have a firm opinion on
'active support' vs. 'security only' - I think the latter much more
closely defines what people truly care about in terms of whether
they feel comfortable having the version still deployed or not.At the very least I think we should give 5.6 24 months of lifetime
from PHP 7.0's release date (i.e. take it until Dec 2017),
I agree having only 8 months (active support) + 12 months (security)
seems very short.
I will really prefer to have cycle aligned to new version
so active support until Dec 2016
and security support until Dec 2017.
but I think we should also consider either extending it even
further, or at least paying attention to the situation on the
ground in terms of PHP 5's popularity as we get closer to that EOL
date. Personally I'm leaning towards having a firm date further
down the road than a 'flexible' one, so that we give people a clear
and reasonable timeline to upgrade - without risking that they
"won't take us seriously" and assume we'd delay the EOL.
Yes, It make sense to me to extend, if needed, for some more months
the security only time.
And of course, this sould be planed and announced as soon as possible
(still possible to extend, but not to reduce, after annoucement).
Remi.
Zeev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlZkeDkACgkQYUppBSnxahjkZACgjkrXHjrVELOUQsYfyRpd6jMW
5LwAoIkqGb0eJeJaeFTQd++W1kPg5d3p
=KiiI
-----END PGP SIGNATURE
Am 06.12.2015 um 19:02 schrieb Remi Collet:
so active support until Dec 2016
and security support until Dec 2017.
Dec 2016 / Dec 2017 makes sense to me.
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).
We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?
I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.
Stas Malyshev
smalyshev@gmail.com
On Sun, Dec 6, 2015 at 4:43 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.Stas Malyshev
smalyshev@gmail.com--
From my perspective, people already have until the end of 2017 to switch
to PHP 7. I think Long Term Support (TM) is generally an anti-pattern that
promotes negligence and makes it harder to ensure people are running the
latest security updates.
Giving everyone until the end of 2017 to update their servers is more than
sufficient.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi!
Giving everyone until the end of 2017 to update their servers is more
than sufficient.
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way or say "you are on your own now, we don't care about you anymore".
Stas Malyshev
smalyshev@gmail.com
On Sun, Dec 6, 2015 at 6:17 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Giving everyone until the end of 2017 to update their servers is more
than sufficient.Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way
or say "you are on your own now, we don't care about you anymore".Stas Malyshev
smalyshev@gmail.com
We should do everything we can to instill a culture of keeping stuff up to
date. Just because people are going to shoot themselves in the foot doesn't
mean we should supply them with additional ammo.
If 2/3 of sites still run EOLed versions of PHP, all adding a long-term
support version is going to do is encourage habits of inertia. "Well, 5.6
was supported until 2020, why can't 7.0.0 be supported until past 2019?
This isn't fair."
or say "you are on your own now, we don't care about you anymore".
Yes, given the lack of a sensible alternative, I think we need to do this.
And then the community needs to, collectively, invest serious effort in
finding a remotely exploitable vulnerability in any/all EOL'd versions of
PHP to give a strong incentive to stop running 5.2.x and 5.3.x in 2016.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
I agree with Scott. With each extension we only seem to be enabling people
with bad habits. 8 months is almost a full year and more than enough time.
On Sun, Dec 6, 2015 at 6:51 PM, Scott Arciszewski scott@paragonie.com
wrote:
On Sun, Dec 6, 2015 at 6:17 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:Hi!
Giving everyone until the end of 2017 to update their servers is more
than sufficient.Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way
or say "you are on your own now, we don't care about you anymore".Stas Malyshev
smalyshev@gmail.comWe should do everything we can to instill a culture of keeping stuff up to
date. Just because people are going to shoot themselves in the foot doesn't
mean we should supply them with additional ammo.If 2/3 of sites still run EOLed versions of PHP, all adding a long-term
support version is going to do is encourage habits of inertia. "Well, 5.6
was supported until 2020, why can't 7.0.0 be supported until past 2019?
This isn't fair."
or say "you are on your own now, we don't care about you anymore".Yes, given the lack of a sensible alternative, I think we need to do this.
And then the community needs to, collectively, invest serious effort in
finding a remotely exploitable vulnerability in any/all EOL'd versions of
PHP to give a strong incentive to stop running 5.2.x and 5.3.x in 2016.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi!
If 2/3 of sites still run EOLed versions of PHP, all adding a long-term
support version is going to do is encourage habits of inertia. "Well,
You seem to be under impression that we have some control over these
habits. We do not. There are a lot of factors that influence these
decisions, but out "encouraging" or "not encouraging" would not even
enter top 10. The reality is that adoption did not catch up yet, and I
do not see how we can change it - we can only recognize it or ignore it
(and call it "not encouraging"). Unless you can name something that we
can really do to make people upgrade (and no, dropping support wouldn't
work, we already know that).
5.6 was supported until 2020, why can't 7.0.0 be supported until past
2019? This isn't fair."
I'm not sure what you mean by "fair" here. There's no inherent moral
obligation on support timeframes, so the word "fair" has no meaning here.
Yes, given the lack of a sensible alternative, I think we need to do
this. And then the community needs to, collectively, invest serious
But that lack is not given, the sensible alternative exists - extending
the support. The premise that this alternative is not sensible is
exactly the question under discussion, so you can not use it as an
argument without engaging in circular reasoning.
effort in finding a remotely exploitable vulnerability in any/all EOL'd
versions of PHP to give a strong incentive to stop running 5.2.x and
5.3.x in 2016.
Community doesn't need to do any such thing, exploitable vulnerabilities
exist in many old versions already. However, I hope you are not implying
we should be somehow making exploiting old versions easier in a
misguided attempt to get people to upgrade? That would be like setting
somebody's home on fire in order to educate them about fire safety.
--
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev in php.internals (Sun, 6 Dec 2015 15:17:53 -0800):
Hi!
Giving everyone until the end of 2017 to update their servers is more
than sufficient.Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions.
I know why we are still running PHP 5.3 for some sites: they are Drupal6
sites. Last time we checked it, PHP 5.4 gave all kinds of warnings with
Drupal6 and PHP 5.3 did not.
Legacy sites? Yes, but not that much. We had been waiting for Drupal8 to
upgrade, but Drupal8 was postponed and postponed and... (Sorry, Larry).
Now it is finally released.
Jan
Stanislav Malyshev in php.internals (Sun, 6 Dec 2015 15:17:53 -0800):
Hi!
Giving everyone until the end of 2017 to update their servers is more
than sufficient.
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions.
I know why we are still running PHP 5.3 for some sites: they are Drupal6
sites. Last time we checked it, PHP 5.4 gave all kinds of warnings with
Drupal6 and PHP 5.3 did not.Legacy sites? Yes, but not that much. We had been waiting for Drupal8 to
upgrade, but Drupal8 was postponed and postponed and... (Sorry, Larry).
Now it is finally released.
No offense taken. :-) Although my Drupal 6 blog (www.garfieldtech.com)
is running successfully on PHP 5.6 right now. You just have to make
sure you're on the latest version of core and contrib modules.
I do not know what Drupal 6's PHP 7 status is, although Drupal 6 support
ends 1 March, I believe. Drupal 7 mostly works but has a few test
failures we'll be looking into shortly.
--Larry Garfield
Giving everyone until the end of 2017 to update their servers is more
than sufficient.
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions.
I know why we are still running PHP 5.3 for some sites: they are Drupal6
sites. Last time we checked it, PHP 5.4 gave all kinds of warnings with
Drupal6 and PHP 5.3 did not.
Little has changed since the upgrade problems PHP5.4 introduced, and
since the vast majority of PHP5.2/3 users ARE users of third party
applications rather than PHP itself, they do not have the competence to
'bug fix' their current working systems and support has often dried up
for the third party elements they are using.
It is not simply a matter of telling people that they have to change but
rather helping them to change, and ISP's have no apparent interest in
providing that support so continue to roll out the easy route? From what
I am seeing, code that has already been brought up to PHP5.6 E_STRICT
'clean' will simply roll over on to PHP7 without a problem, it is still
cleaning up the legacy code which is the problem and there is no easy
way to do that. "It's just a few hours work" does not help the millions
of people who sometimes would not even know they are using PHP!
Continuing to run PHP5.2 is the right choice for those people, and ISP's
seem to be handling the fallout of security risk by security updates on
that infrastructure rather than trying to eliminate the legacy code.
In the past we have been told "Just switch off the warnings and your
code will carry on working", but that was ALWAYS the wrong answer and
cleaning the code at each upgrade IS the only way to keep legacy code
bases tidy? Providing PHP7 clean alternatives with usable upgrade paths
is the only way that PHP5.2/3 can be deprecated fully, so any debate on
an arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
disappear ... now unlikely it ever will? Is PHP5.2 any different?
--
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
Lester Caine wrote on 07/12/2015 09:42:
Providing PHP7 clean alternatives with usable upgrade paths is the
only way that PHP5.2/3 can be deprecated fully, so any debate on an
arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
disappear ... now unlikely it ever will? Is PHP5.2 any different?
People said the same about PHP 4, but eventually it did disappear, and I
think 5.2 is well down the same road (counting 5.3 as being 6.0 in all
but name).
Lester Caine wrote on 07/12/2015 09:42:
Providing PHP7 clean alternatives with usable upgrade paths is the
only way that PHP5.2/3 can be deprecated fully, so any debate on an
arbitrary EOL for 5.6 is simple pie in the sky? When will Python2
disappear ... now unlikely it ever will? Is PHP5.2 any different?People said the same about PHP 4, but eventually it did disappear, and I
think 5.2 is well down the same road (counting 5.3 as being 6.0 in all
but name).
Things are certainly heading in the right direction, but 5.2/3 is still
only dropped bellow 50% in the last month, while PHP4 was well down when
the actual EOL was proposed. 80% of people were using PHP5.2 in 2010
against 20% on PHP4, and that swung to 90/10 in 2011 mainly because PHP4
sites could be switched to PHP5.2 ... switching 5.2/3 sites to PHP7 is
not so easy, but
http://w3techs.com/technologies/history_details/pl-php/5/y probably
shows the best picture, with people migrating to PHP5.4 as the next step
...
--
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
Lester Caine wrote on 07/12/2015 11:47:
Things are certainly heading in the right direction, but 5.2/3 is still
only dropped bellow 50% in the last month, while PHP4 was well down when
the actual EOL was proposed. 80% of people were using PHP5.2 in 2010
against 20% on PHP4, and that swung to 90/10 in 2011 mainly because PHP4
sites could be switched to PHP5.2 ... switching 5.2/3 sites to PHP7 is
not so easy, but
http://w3techs.com/technologies/history_details/pl-php/5/y probably
shows the best picture, with people migrating to PHP5.4 as the next step
...
Bundling 5.2 and 5.3 into one bracket seems very odd to me. In my mind,
the major upgrades are 4 to 5, 5.2 to 5.3 (which should have been 6.0),
maybe 5.4 (for things like the call-time pass-by-reference cleanup),
then plain sailing up to 5.6.
I would guess that delays in adopting 5.5 and 5.6 are probably more to
do with package availability in enterprise Linux distros (and shared
hosting), and a lack of killer features which people go out of their way
to upgrade for, rather than the difficulty of adapting code. It's
probably actually easier to make the business case for a 7.0 upgrade
than a 5.6 one.
Regards,
Rowan Collins
[IMSoP]
Lester Caine wrote on 07/12/2015 11:47:
Things are certainly heading in the right direction, but 5.2/3 is still
only dropped bellow 50% in the last month, while PHP4 was well down when
the actual EOL was proposed. 80% of people were using PHP5.2 in 2010
against 20% on PHP4, and that swung to 90/10 in 2011 mainly because PHP4
sites could be switched to PHP5.2 ... switching 5.2/3 sites to PHP7 is
not so easy, but
http://w3techs.com/technologies/history_details/pl-php/5/y probably
shows the best picture, with people migrating to PHP5.4 as the next step
...Bundling 5.2 and 5.3 into one bracket seems very odd to me. In my mind,
the major upgrades are 4 to 5, 5.2 to 5.3 (which should have been 6.0),
maybe 5.4 (for things like the call-time pass-by-reference cleanup),
then plain sailing up to 5.6.
PHP5.2 code runs on PHP5.3 with the right configuration of error
checking. It is PHP5.4 which replaces the 'deprecated' by removing the
code altogether, so in my book PHP5.4 is '6' not 5.3 ... simply hiding
problems in PHP5.3 still required that they were fixed at some point!
I would guess that delays in adopting 5.5 and 5.6 are probably more to
do with package availability in enterprise Linux distros (and shared
hosting), and a lack of killer features which people go out of their way
to upgrade for, rather than the difficulty of adapting code. It's
probably actually easier to make the business case for a 7.0 upgrade
than a 5.6 one.
Many people adopted the convention of running PHP5.4 in parallel with
the PHP5.2/3 servers and certainly in my own portfolio until everything
has been moved to PHP5.4 then nothing will move on to a later build. But
given the lack of any obvious blockers in PHP7 once all the PHP5.4 code
IS running clean, PHP7 seems just as easy a step as PHP5.6 its getting
the PHP5.2/3 code past that step which is the current blocker not helped
by trying to keep the resulting html code compatible with modern
browsers. THAT is another drain on limited resources and detracting from
completing other upgrades.
I'm not seeing any reports of any particular problems on PHP7. Is that
simply because no-one has started testing on legacy code yet, or that
the breakages in PHP7 are actually not show stoppers for PHP5.6 code?
Certainly I'm not seeing any against my own code, but I still need to
complete some work before I can do full speed comparisons against the
PHP5.4/eaccelerator setup ... something else that is stuck at PHP5.4.
--
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
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way or say "you are on your own now, we don't care about you anymore".
People who don't update aren't really relevant for a lifetime
discussion. It doesn't really matter if they don't update to 5.6 or if
they don't update to 7.0. Especially if they don't even update from
5.3.x to 5.3.(x+n).
johannes
The EOL (end of life) date does influence people. True, not everyone will
simply jump ship upon EOL. But it is still has a significant enough
influence on adoption and urgency in general. Especially toward new
development projects or new releases in general that are less likely to
code with support for EOL products (overall). There is an influencing
factor that cannot be realistically denied without avoiding common sense.
On Tue, Dec 8, 2015 at 7:19 AM, Johannes Schlüter johannes@schlueters.de
wrote:
Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way or say "you are on your own now, we don't care about you
anymore".People who don't update aren't really relevant for a lifetime
discussion. It doesn't really matter if they don't update to 5.6 or if
they don't update to 7.0. Especially if they don't even update from
5.3.x to 5.3.(x+n).johannes
Den 2015-12-08 kl. 16:00, skrev Adam Howard:
The EOL (end of life) date does influence people. True, not everyone will
simply jump ship upon EOL. But it is still has a significant enough
influence on adoption and urgency in general. Especially toward new
development projects or new releases in general that are less likely to
code with support for EOL products (overall). There is an influencing
factor that cannot be realistically denied without avoiding common sense.On Tue, Dec 8, 2015 at 7:19 AM, Johannes Schlüter johannes@schlueters.de
wrote:Sufficient for what? It is a hard fact that people still run 5.3
version. In fact, 2/3 of sites run EOLed versions. You can always say
they have only themselves to blame, but then I'm not sure what
"sufficient" means. Unless adoption patterns change drastically, by the
end of 2017 most people will not be running PHP 7. That's not something
we can realistically change (unless you have some way of changing those
patterns we didn't try yet or they change by themselves somehow). Thus,
our choice lies only in whether we support this majority of users in
some way or say "you are on your own now, we don't care about you
anymore".People who don't update aren't really relevant for a lifetime
discussion. It doesn't really matter if they don't update to 5.6 or if
they don't update to 7.0. Especially if they don't even update from
5.3.x to 5.3.(x+n).johannes
--
Actually our ISP is now offering PHP 7.0 in their production environment
for all
customers. So the 5.6 support timeline was not relevant in that case.
For us as
application developers I'm not sure it matters so much since we today
runs on
an older PHP version. The business case going for 7.0 is so good that I
see no
point going for 5.6 and then 7.0.
Regards //Björn
PS Of course for a larger organisation then us it has another impact,
but the
tentative cost savings and performance gains with 7.0 is a strong
driving force.
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).
We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.
Drupal has maintained a current-stable and last-stable version for most
of its history, with those two versions not being API-compatible. After
the first few months, if anything it's the last-stable that gets
effectively unmaintained by extension developers who want to work with
the new shiny.
To be sure, Drupal and PHP are a different dynamic and target audience
but at least in my experience "only maintain PHP 5 extension, not PHP 7"
seems like a very unlikely problem, especially once a PHP 7-version of a
library exists.
--Larry Garfield
Adding extended support does justify (provide an excuse) for others not
adapt or upgrade to new code. While PHP Development obvious cannot control
the actions of others (obviously), extending support does unintentionally
enables poor practices. Once support is ended, people do begin to migrate.
I do not believe 5.6 should be given extended support and it should be
treated as any previous release.
On Mon, Dec 7, 2015 at 12:17 AM, Larry Garfield larry@garfieldtech.com
wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.Drupal has maintained a current-stable and last-stable version for most of
its history, with those two versions not being API-compatible. After the
first few months, if anything it's the last-stable that gets effectively
unmaintained by extension developers who want to work with the new shiny.To be sure, Drupal and PHP are a different dynamic and target audience but
at least in my experience "only maintain PHP 5 extension, not PHP 7" seems
like a very unlikely problem, especially once a PHP 7-version of a library
exists.--Larry Garfield
Hi Stas,
Stanislav Malyshev wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?
As others have pointed out, there's also the problem of PHP 5 lifetime
extension reducing the urgency for users to move to 7.
I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.
Support for 5.6 ends in August 2017, that's 20 months away. So it's not
quite as bad as that.
Thanks.
--
Andrea Faulds
http://ajf.me/
I see the same people who had a problem with the EOL (end of life) date for
5.4, 5.5, are going to be the same people who have a problem with 5.6 EOL.
Extended the support will only enable those and others to validate their
excuse for not needing to migrate to the new code base.
I agree, a date should be made and set.
Hi Stas,
Stanislav Malyshev wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as it's
the last version that's relatively completely painless to upgrade to from
5.x (especially 5.3 and later).We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for 7?As others have pointed out, there's also the problem of PHP 5 lifetime
extension reducing the urgency for users to move to 7.I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.Support for 5.6 ends in August 2017, that's 20 months away. So it's not
quite as bad as that.Thanks.
--
Andrea Faulds
http://ajf.me/
2016, not 2017. Extended support for nearly 2 years is a bad idea and only
further enables bad practices.
I see the same people who had a problem with the EOL (end of life) date
for 5.4, 5.5, are going to be the same people who have a problem with 5.6
EOL. Extended the support will only enable those and others to validate
their excuse for not needing to migrate to the new code base.I agree, a date should be made and set.
Hi Stas,
Stanislav Malyshev wrote:
Hi!
IMHO, I think we need to look at the 5.6 lifecycle very differently from
how we look at 5.5 and earlier. This is really the 5.x lifecycle as
it's
the last version that's relatively completely painless to upgrade to
from
5.x (especially 5.3 and later).We could make 5.6 an LTS release with extended support, but the question
is given the code delta, would all fixes' authors be willing to do
essentially double work? Would extension authors be willing to maintain
two branches long-term? And, if that proves to be hard - wouldn't we end
up with a situation where they choose to only maintain PHP 5 version
(since it's easier and that's where 90% of people are) and extensions go
unsupported for PHP 7 for a long time, creating an adoption problem for
7?As others have pointed out, there's also the problem of PHP 5 lifetime
extension reducing the urgency for users to move to 7.I do think we probably need to extend the lifetime of 5.6 (and make an
RFC on it) since I see no way to have everybody to adopt PHP 7 in mere 8
months, but we should have a defined EOL date ASAP.Support for 5.6 ends in August 2017, that's 20 months away. So it's not
quite as bad as that.Thanks.
--
Andrea Faulds
http://ajf.me/
Jan Ehrhardt in php.internals (Sun, 06 Dec 2015 13:14:57 +0100):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?
Oops. Corrected:
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2016 with a end of
life on 28 Aug 2017? Or will we be postponing this a couple of months?
BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.html
Windows users will have a problem then after 2016-12-31. A way out would
be to compile PHP 5.6 in 2017 with OpenSSL 1.0.2.
Jan
Am 06.12.2015 um 13:14 schrieb Jan Ehrhardt:
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016?
I hope that we stick to the current plan of ending support for PHP 5
on 28 Aug 2016. If we don't, then please decide on an EOL date for
PHP 5 and announce it ASAP. Lets not repeat the mistakes we made with
PHP 4.
Am 06.12.2015 um 15:45 schrieb Sebastian Bergmann:
I hope that we stick to the current plan of ending support for PHP 5
"support" should have been "active support". Sorry for the noise.
Am 06.12.2015 um 13:14 schrieb Jan Ehrhardt:
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016?I hope that we stick to the current plan of ending support for PHP 5
on 28 Aug 2016. If we don't, then please decide on an EOL date for
PHP 5 and announce it ASAP. Lets not repeat the mistakes we made with
PHP 4.
I am okay with a date later than 2016-08-28 but I do agree we should
choose the date and stick to it. I do not think we should re-evaluate
adoption of PHP 7 in one year and choose a new EOL for PHP 5 based on
that information. A planned roadmap is better for everyone.
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
Since the rfc for 5.7 failed the voting I've personally assumed that we
don't want to support the 5.x series after the normal lifecycle for 5.6:
https://wiki.php.net/rfc/php57
Most of my arguments for 5.7 was the same as Zeev and orhers listed here in
this thread but the majority shared the opinion that the support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it will
just delay the adoption for 7.0
Ferenc Kovacs in php.internals (Sun, 6 Dec 2015 17:32:25 +0100):
Since the rfc for 5.7 failed the voting I've personally assumed that we
don't want to support the 5.x series after the normal lifecycle for 5.6:
https://wiki.php.net/rfc/php57
That RFC was based on a proposed timeline for PHP7 with a GA release "Mid
October 2015". We did not make that. And, besides that, we are living
almost a year later now. An accepted RFC of one year ago should not stop
us thinking about what we think is the best option now.
Jan
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
Since the rfc for 5.7 failed the voting I've personally assumed that we
don't want to support the 5.x series after the normal lifecycle for 5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed here in
this thread but the majority shared the opinion that the support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it will
just delay the adoption for 7.0
I can't say anything as to what majorities think, but while I did not want
a PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me adverse
to extending the PHP 5.6 support cycle. I would go as far as saying that us
not having done a PHP 5.7 release is an argument in favor of prolonging
support for PHP 5.6, not the reverse.
Nikita
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Sunday, December 06, 2015 7:03 PM
To: Ferenc Kovacs
Cc: Jan Ehrhardt; PHP Internals
Subject: Re: [PHP-DEV] PHP 5.6 life cycle
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end
of life on 28 Aug 2016? Or will we be postponing this a couple of
months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of
OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
To unsubscribe,
visit: http://www.php.net/unsub.phpSince the rfc for 5.7 failed the voting I've personally assumed that
we don't want to support the 5.x series after the normal lifecycle for
5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed
here in this thread but the majority shared the opinion that the
support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it
will just delay the adoption for 7.0I can't say anything as to what majorities think, but while I did not want
a
PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me
adverse to extending the PHP 5.6 support cycle. I would go as far as
saying
that us not having done a PHP 5.7 release is an argument in favor of
prolonging support for PHP 5.6, not the reverse.
I agree completely.
Ferenc - the way I see it, 5.7 actually had little to do with the arguments
I brought up. I believe that the main reason 5.7 was opposed (at least I
can at least speak for myself) is that people felt it wasn't a good idea to
divide our attention from delivering 7.0, something that 5.7 (even if the
only new features were forward compatibility, and more realistically -
packing extra features) would have done.
Sebastian - while it's obvious that us supporting PHP 5.6 for a while longer
does have some effect on migration to 7.0, realistically, we can't force
millions of people to upgrade on our own timeline if it's too short. On
such a short timeline, what it practically means is that there are going to
be a lot more websites that won't migrate on time and will become insecure
on September 2017. Also, discontinuing support for PHP 5.6 in August means
you'd have less time to migrate from 5.6 to 7.0 than you did to upgrade from
5.5 to 5.6 - and that was a painless upgrade. What if 7.0 was delayed by a
few more months? Or a year? Both seemed like likely scenarios back when we
called the 7.0 timeline aggressive. The 'sin' of the PHP 4 EOL was - well -
that we didn't have one for a very long time. We should definitely have a
clear one for 5.6, but it should be more realistic than 1.5yrs away.
In general, I don't think timelines make sense to commit to before a version
is released. If for whatever reason a release gets delayed it makes no
sense that you'd be forced, as a user, for a shorter upgrade cycle.
Something along the lines of Francois' suggestion - where the lifetime of
version N-1 relates to the release date of version N is definitely needed,
and that was the thinking behind the release process timeline to begin with.
Zeev
Le 06/12/2015 18:36, Zeev Suraski a écrit :
The 'sin' of the PHP 4 EOL was - well -
that we didn't have one for a very long time.
An important 'sin' of the PHP 4 EOL is also the massive backport of PHP
5 features during years, which didn't push people to migrate.
In general, I don't think timelines make sense to commit to before a version
is released. If for whatever reason a release gets delayed it makes no
sense that you'd be forced, as a user, for a shorter upgrade cycle.
Something along the lines of Francois' suggestion - where the lifetime of
version N-1 relates to the release date of version N is definitely needed,
and that was the thinking behind the release process timeline to begin with.
Yes, starting counting from the release date of version N is better. So,
instead of giving one additional year of support, what about a guarantee
of 2 years of active support on <N - 1>.<last> starting from <N>.0
release date ? That would extend 5.6 active support to Dec 2017, and EOL
on Dec 2018, which is a good trade-off, IMHO.
Regards
François
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Sunday, December 06, 2015 7:03 PM
To: Ferenc Kovacs
Cc: Jan Ehrhardt; PHP Internals
Subject: Re: [PHP-DEV] PHP 5.6 life cycle
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end
of life on 28 Aug 2016? Or will we be postponing this a couple of
months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of
OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
To unsubscribe,
visit: http://www.php.net/unsub.phpSince the rfc for 5.7 failed the voting I've personally assumed that
we don't want to support the 5.x series after the normal lifecycle for
5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed
here in this thread but the majority shared the opinion that the
support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it
will just delay the adoption for 7.0I can't say anything as to what majorities think, but while I did not want
a
PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me
adverse to extending the PHP 5.6 support cycle. I would go as far as
saying
that us not having done a PHP 5.7 release is an argument in favor of
prolonging support for PHP 5.6, not the reverse.
I agree completely.Ferenc - the way I see it, 5.7 actually had little to do with the arguments
I brought up. I believe that the main reason 5.7 was opposed (at least I
can at least speak for myself) is that people felt it wasn't a good idea to
divide our attention from delivering 7.0, something that 5.7 (even if the
only new features were forward compatibility, and more realistically -
packing extra features) would have done.Sebastian - while it's obvious that us supporting PHP 5.6 for a while longer
does have some effect on migration to 7.0, realistically, we can't force
millions of people to upgrade on our own timeline if it's too short. On
such a short timeline, what it practically means is that there are going to
be a lot more websites that won't migrate on time and will become insecure
on September 2017. Also, discontinuing support for PHP 5.6 in August means
you'd have less time to migrate from 5.6 to 7.0 than you did to upgrade from
5.5 to 5.6 - and that was a painless upgrade. What if 7.0 was delayed by a
few more months? Or a year? Both seemed like likely scenarios back when we
called the 7.0 timeline aggressive. The 'sin' of the PHP 4 EOL was - well -
that we didn't have one for a very long time. We should definitely have a
clear one for 5.6, but it should be more realistic than 1.5yrs away.In general, I don't think timelines make sense to commit to before a version
is released. If for whatever reason a release gets delayed it makes no
sense that you'd be forced, as a user, for a shorter upgrade cycle.
Something along the lines of Francois' suggestion - where the lifetime of
version N-1 relates to the release date of version N is definitely needed,
and that was the thinking behind the release process timeline to begin with.Zeev
Coming from user-space, +1 to the "an extra year over whatever it would
have had" for the last release within a major. While I'm champing at
the bit to use PHP 7 and will be trying to push others to do the same,
realistically it is a bumpier upgrade than 5.5->5.6 (duh) so giving
people extra breathing room to plan an upgrade is a good thing. Whether
that's an extra year of active support or security support, I don't feel
strongly. (Maybe making it security support will be a better upgrade
incentive?)
That said, I also agree that a fixed date is mandatory, or people won't
feel any pressure. The drop-dead date is important for planning and
messaging, just as we saw with GoPHP5.
That extra year is also helpful to all the big projects that just
increased their minimum version to 5.5. (Drupal, Symfony, Zend
Framework, Guzzle, etc.) I expect most projects are going to skip 5.6
as a minimum required version and jump straight to 7, just like many
skipped 5.4, but they'll need to see more server offerings. It will be
an easier case to make in 2 years for the next version of all of those
projects to go to 7.x if 5.6 is sec-only with a known drop-dead date,
but not entirely abandoned so we have some breathing room until then.
--Larry Garfield
Hi,
-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Sunday, December 6, 2015 8:01 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.6 life cycle-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Sunday, December 06, 2015 7:03 PM
To: Ferenc Kovacs
Cc: Jan Ehrhardt; PHP Internals
Subject: Re: [PHP-DEV] PHP 5.6 life cycle
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a
end of life on 28 Aug 2016? Or will we be postponing this a couple
of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of
OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
To
unsubscribe,
visit: http://www.php.net/unsub.phpSince the rfc for 5.7 failed the voting I've personally assumed that
we don't want to support the 5.x series after the normal lifecycle
for
5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed
here in this thread but the majority shared the opinion that the
support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it
will just delay the adoption for 7.0I can't say anything as to what majorities think, but while I did not
want a PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me
adverse to extending the PHP 5.6 support cycle. I would go as far as
saying that us not having done a PHP 5.7 release is an argument in
favor of prolonging support for PHP 5.6, not the reverse.
I agree completely.Ferenc - the way I see it, 5.7 actually had little to do with the
arguments I brought up. I believe that the main reason 5.7 was
opposed (at least I can at least speak for myself) is that people felt
it wasn't a good idea to divide our attention from delivering 7.0,
something that 5.7 (even if the only new features were forward
compatibility, and more realistically - packing extra features) would have
done.Sebastian - while it's obvious that us supporting PHP 5.6 for a while
longer does have some effect on migration to 7.0, realistically, we
can't force millions of people to upgrade on our own timeline if it's
too short. On such a short timeline, what it practically means is
that there are going to be a lot more websites that won't migrate on
time and will become insecure on September 2017. Also, discontinuing
support for PHP 5.6 in August means you'd have less time to migrate
from 5.6 to 7.0 than you did to upgrade from
5.5 to 5.6 - and that was a painless upgrade. What if 7.0 was delayed
by a few more months? Or a year? Both seemed like likely scenarios
back when we called the 7.0 timeline aggressive. The 'sin' of the PHP
4 EOL was - well - that we didn't have one for a very long time. We
should definitely have a clear one for 5.6, but it should be more realistic than
1.5yrs away.In general, I don't think timelines make sense to commit to before a
version is released. If for whatever reason a release gets delayed it
makes no sense that you'd be forced, as a user, for a shorter upgrade cycle.
Something along the lines of Francois' suggestion - where the lifetime
of version N-1 relates to the release date of version N is definitely
needed, and that was the thinking behind the release process timeline to begin
with.Zeev
Coming from user-space, +1 to the "an extra year over whatever it would have
had" for the last release within a major. While I'm champing at the bit to use
PHP 7 and will be trying to push others to do the same, realistically it is a
bumpier upgrade than 5.5->5.6 (duh) so giving people extra breathing room to
plan an upgrade is a good thing. Whether that's an extra year of active support
or security support, I don't feel strongly. (Maybe making it security support will
be a better upgrade
incentive?)That said, I also agree that a fixed date is mandatory, or people won't feel any
pressure. The drop-dead date is important for planning and messaging, just as
we saw with GoPHP5.That extra year is also helpful to all the big projects that just increased their
minimum version to 5.5. (Drupal, Symfony, Zend Framework, Guzzle, etc.) I
expect most projects are going to skip 5.6 as a minimum required version and
jump straight to 7, just like many skipped 5.4, but they'll need to see more server
offerings. It will be an easier case to make in 2 years for the next version of all
of those projects to go to 7.x if 5.6 is sec-only with a known drop-dead date, but
not entirely abandoned so we have some breathing room until then.
From today's perspective, I'd suggest to extend the security only period of 5.6. Virtually, most of the core devs are concentrated on improving and bringing forward 7. That means what is called "active development" doesn't really match the reality, per fact. And per the tendency, that could most likely get ever more obvious.
Clear, there will be always customers not willing to upgrade, just like today there are quite some still running even PHP 4. However those are real legacy applications which can't be supported endlessly, and it is well known. Telling that 5.6 will stay stable and secure for the extended security only period is probably honest and fair with respect to both the core devs and to the users.
Most likely the end decision would make sense to be evaluated in summer 2016 when the developments in the real world are evident. It could be, that an extension is not required. Or it could be, that the "active development" phase is required to continue very much. We also depend very much on the decisions of other projects, be it distributions or PHP core dependencies.
Regards
Anatol
Le 06/12/2015 20:38, Anatol Belski a écrit :
Virtually, most of the core devs are concentrated on improving and bringing forward 7. That means what is called "active development" doesn't really match the reality, per fact.
That's 'active support', not 'active development'. It means that we
accept every bug reports, even not security-related. If we extend the
security-only period, the support of the whole 5.x for
non-security-related bugs stops in 8 months. Easier for us but too short
for users IMHO.
Regards
François
8 months is fine. It is more than enough time for people to upgrade and
adapt. Extending support longer only extends the excuse for other
developments not to upgrade and adapt, as history has proven time and time
again.
Le 06/12/2015 20:38, Anatol Belski a écrit :
Virtually, most of the core devs are concentrated on improving and
bringing forward 7. That means what is called "active development" doesn't
really match the reality, per fact.That's 'active support', not 'active development'. It means that we accept
every bug reports, even not security-related. If we extend the
security-only period, the support of the whole 5.x for non-security-related
bugs stops in 8 months. Easier for us but too short for users IMHO.Regards
François
Adam Howard in php.internals (Sun, 6 Dec 2015 18:07:53 -0500):
8 months is fine. It is more than enough time for people to upgrade and
adapt.
It ain't. If you have got large sites that are built with a framework that
requires an older PHP-version you will have to (a) convince the site owner
that an upgrade is absolutely necessary, (b) agree on the functional specs
of the site after the upgrade, (c) agree on a price quote with the content
owner, (d) get that quote accepted by the purchase department of the site
owner. Each of these steps can easily take several months and then you are
not even starting building.
Jan
Adam Howard in php.internals (Sun, 6 Dec 2015 18:07:53 -0500):
8 months is fine. It is more than enough time for people to upgrade and
adapt.It ain't. If you have got large sites that are built with a framework that
requires an older PHP-version you will have to (a) convince the site owner
that an upgrade is absolutely necessary, (b) agree on the functional specs
of the site after the upgrade, (c) agree on a price quote with the content
owner, (d) get that quote accepted by the purchase department of the site
owner. Each of these steps can easily take several months and then you are
not even starting building.Jan
--
Where did this 8 months figure come from?
PHP 7.0.0 available -> 2015-12-03
Today -> 2015-12-06
PHP 5.6.x EOL'd -> 2017-08
That's more than 8 months.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Scott Arciszewsk, I read the 8 month suggestion that someone else brought
up. I do not recall who brought it up, but I think 2017 is far too much
time. It only further enables bad practices.
Jan Ehrhardt, That is not PHP's responsibility, that is your responsibility
to update your own code. No one is going to force you to update, but it
should not be PHP Development's strance to further enable people to use old
code.
On Sun, Dec 6, 2015 at 7:38 PM, Scott Arciszewski scott@paragonie.com
wrote:
Adam Howard in php.internals (Sun, 6 Dec 2015 18:07:53 -0500):
8 months is fine. It is more than enough time for people to upgrade and
adapt.It ain't. If you have got large sites that are built with a framework
that
requires an older PHP-version you will have to (a) convince the site
owner
that an upgrade is absolutely necessary, (b) agree on the functional
specs
of the site after the upgrade, (c) agree on a price quote with the
content
owner, (d) get that quote accepted by the purchase department of the site
owner. Each of these steps can easily take several months and then you
are
not even starting building.Jan
--
Where did this 8 months figure come from?
PHP 7.0.0 available -> 2015-12-03
Today -> 2015-12-06
PHP 5.6.x EOL'd -> 2017-08
That's more than 8 months.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
From today's perspective, I'd suggest to extend the security only period of 5.6.
That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but then give it two years of security fixes instead of just one.
From today's perspective, I'd suggest to extend the security only period
of 5.6.That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but then
give it two years of security fixes instead of just one.
It would be less of a burden both from the maintenance and Release Manager
perspective, so +1 from me.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hello internals,
In my opinion, right now what dictates the timeframes is Release Process
RFC: https://wiki.php.net/rfc/releaseprocess
It clearly states the rules of how things are done.
If dates for the PHP 5.6 are to be adjusted, than it requires an RFC
process and should be an exception, not the rule.
But, for what it's worth - it's fine as it is. Distros will support 5.6 as
long as they need, you can always download older versions for Windows from
php.net archive and so on. It still has almost 2 years in security fixes
left, and that's more than enough time for people to make a move. Others
will just not care to do that anyway for whatever reasons, and nothing can
be done about it.
Arvids.
Hello internals,
In my opinion, right now what dictates the timeframes is Release Process
RFC: https://wiki.php.net/rfc/releaseprocess
It clearly states the rules of how things are done.
If dates for the PHP 5.6 are to be adjusted, than it requires an RFC
process and should be an exception, not the rule.But, for what it's worth - it's fine as it is. Distros will support 5.6 as
long as they need, you can always download older versions for Windows from
php.net archive and so on. It still has almost 2 years in security fixes
left, and that's more than enough time for people to make a move. Others
will just not care to do that anyway for whatever reasons, and nothing can
be done about it.
We need to be aware that there are 3 types of user:
-
those who run PHP on a machine provided by their ISP
-
those who run their machine using software that comes ''with the operating system'',
I am thinking of Linux users, mainly: RedHat, Debian, SUSE -
those who are happy & able to upgrade their machine to the something
reasonably recent.
Those who I want to talk about are (2), they want to have their systems kept up
to date by running a daily cron job (yum update, or apt-get ...). We cannot
rely on these systems being rebuilt, some have very long lifetimes, eg
RedHat/CentOS 7 will be supported until 2024 - and by default runs PHP 5.4
We need to persuade the distros to have PHP 7 available in addition to
whatever PHP 5.x they have. However: they will probably continue to support PHP 5.x
until that version of their OS is EOLed -- which is work that they will have to do.
PHP 5.x will still be in use for many years: people put a machine together to do
something and then don't want to fiddle with it (which might break applications)
for as long as possible. But also they, naturally, want bug fixes.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
From today's perspective, I'd suggest to extend the security only
period of 5.6.That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but then
give it two years of security fixes instead of just one.It would be less of a burden both from the maintenance and Release Manager
perspective, so +1 from me.
compared to extending the active support obviously.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
From today's perspective, I'd suggest to extend the security only period of 5.6.
That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but
then give it two years of security fixes instead of just one.
I think that's indeed the most sensible option. Normal support to Dec
2106, and security til 2018.
cheers,
Derick
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, December 07, 2015 12:41 PM
To: David Zuelke
Cc: Anatol Belski; Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.6 life cycleFrom today's perspective, I'd suggest to extend the security only
period
of 5.6.That would be my suggestion too.
End "full" support in, say, December 2016 (a year after 7.0.0), but
then give it two years of security fixes instead of just one.I think that's indeed the most sensible option. Normal support to Dec
2106,
and security til 2018.
Are you really suggesting to end security fixes 88 years before we end
normal support? :)
Typos aside, that's what I'm leaning towards as well. As I said in one of
my initial notes, I think that ultimately what users care about primarily
is the security support and less so about the 'full maintenance'. That's
what defines the true lifetime of a version.
Ferenc - do you still feel strongly that we should defer the decision into
a later time? I want to know whether to include that as an option in the
RFC. Personally - while there are pros and cons to both directions, I'm
leaning more towards having a clearly defined timeline that we decide on
in advance.
Zeev
Ferenc - do you still feel strongly that we should defer the decision into
a later time? I want to know whether to include that as an option in the
RFC. Personally - while there are pros and cons to both directions, I'm
leaning more towards having a clearly defined timeline that we decide on
in advance.Zeev
I'm fine either way, I don't have a strong case for deferring the decision.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
hi,
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Sunday, December 06, 2015 7:03 PM
To: Ferenc Kovacs
Cc: Jan Ehrhardt; PHP Internals
Subject: Re: [PHP-DEV] PHP 5.6 life cycle
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end
of life on 28 Aug 2016? Or will we be postponing this a couple of
months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of
OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
To unsubscribe,
visit: http://www.php.net/unsub.phpSince the rfc for 5.7 failed the voting I've personally assumed that
we don't want to support the 5.x series after the normal lifecycle for
5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed
here in this thread but the majority shared the opinion that the
support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it
will just delay the adoption for 7.0I can't say anything as to what majorities think, but while I did not want
a
PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me
adverse to extending the PHP 5.6 support cycle. I would go as far as
saying
that us not having done a PHP 5.7 release is an argument in favor of
prolonging support for PHP 5.6, not the reverse.I agree completely.
Ferenc - the way I see it, 5.7 actually had little to do with the arguments
I brought up. I believe that the main reason 5.7 was opposed (at least I
can at least speak for myself) is that people felt it wasn't a good idea to
divide our attention from delivering 7.0, something that 5.7 (even if the
only new features were forward compatibility, and more realistically -
packing extra features) would have done.
And this focus should remain as either fixes in 7.0.x and upcoming
features for 7.1 are not going to slow down. This will remain true for
all 7.x lifetime.
Also for everyone, php 5.6 is already planed to EOL in middle of 2017,
http://php.net/supported-versions.php
I suppose there is confusion between "active" support and EOL. I think
moving 5.6 to security only next year (or some critical blocking bugs
on a case by case bases, RMs deciding) should remain untouched. June
2017 for EOL looks fine to me as well and I see no appealing to reason
to change that.
Sebastian - while it's obvious that us supporting PHP 5.6 for a while longer
does have some effect on migration to 7.0, realistically, we can't force
millions of people to upgrade on our own timeline if it's too short
Many users won't migrate to 7 any time soon, no matter what we do.
Other needs more time, 1-2 years, and they are the ones we should take
care of. And this is what we do right now already.
For them, everything is too short, but for reasons outside php.net's
control. This is why many of us wanted 5.7, to provide an easier
transition post 5.6 for those not able to move to 7 in the next two
years.
Now it is proposed to still do it with 5.6 starting to make exceptions
to our release cycles, despite the rejection of 5.7 earlier this year
to push 7 out. I do not see that as a good move, besides the very
disputable change in how things are presented now, much more as a bad
precedent. Distributions can take care of it after 2017 if necessary,
that's what they kept doing with 5.3/4 and will do with 5.5 as well,
even if the differences between them and 5.6 are smaller than 5.x and
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
Since the rfc for 5.7 failed the voting I've personally assumed that we
don't want to support the 5.x series after the normal lifecycle for 5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed here
in
this thread but the majority shared the opinion that the support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it will
just delay the adoption for 7.0I can't say anything as to what majorities think, but while I did not want
a PHP 5.7 release, with the large amount of additional work and
fragmentation of focus it would have implied, this does not make me adverse
to extending the PHP 5.6 support cycle. I would go as far as saying that us
not having done a PHP 5.7 release is an argument in favor of prolonging
support for PHP 5.6, not the reverse.Nikita
re-reading the archives I tend to agree, even myself mentioned in the 5.7
thread that we could extend the 5.6 lifecycle if the sole reason for 5.7
was to extend the support timeframe for 5.x
so I think that extending the 5.6 lifecycle is fair game, but I think it
would be better to not decide about that now, but wait a bit and see how
the php7 adoption goes first and we can make a more data-based decision
later.
(obviously this would require an RFC and a vote)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
re-reading the archives I tend to agree, even myself mentioned in the 5.7
thread that we could extend the 5.6 lifecycle if the sole reason for 5.7
was to extend the support timeframe for 5.x
so I think that extending the 5.6 lifecycle is fair game, but I think it
would be better to not decide about that now, but wait a bit and see how
the php7 adoption goes first and we can make a more data-based decision
later.(obviously this would require an RFC and a vote)
I think we should decide now whether we want to decide in advance or defer the decision for later (there are pros and cons for both). These can be options in the RFC as well. I'll work on one.
Zeev
- dec. 6. 13:15 ezt írta ("Jan Ehrhardt" phpdev@ehrhardt.nl):
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
--
Since the rfc for 5.7 failed the voting I've personally assumed that we
don't want to support the 5.x series after the normal lifecycle for 5.6:
https://wiki.php.net/rfc/php57Most of my arguments for 5.7 was the same as Zeev and orhers listed here
in
this thread but the majority shared the opinion that the support left for
5.6 is sufficient and we shouldn't prolong the support for 5.x as it will
just delay the adoption for 7.0
Exactly. I am surprised to see ideas about postponing our fixed release
cycles.
I think 5.6 should not be extended. It should be treated like any other
release and given the same length of time originally planned for any
previous release. It should not be the responsibility of PHP Development
to be used as an excuse not to update adapt to newer code standards. Which
is something I feel happens all to often not just with PHP in general, but
regarding technology as a whole.
The PHP Development Team has done a wonderful job with PHP 7.0 and now the
responsibility falls upon others to adapt to that new standard. Of course
5.6 will continue to receive the normal level support as previous releases,
but it should not be extended simply because others choose to drag their
feet.
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?BTW: An end-of-life in Dec 2016 will be in line wih the EOL of OpenSSL
1.0.1: "Version 1.0.1 will be supported until 2016-12-31."
http://openssl.org/policies/releasestrat.htmlJan
Hi,
Jan Ehrhardt wrote:
See http://php.net/supported-versions.php
Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of
life on 28 Aug 2016? Or will we be postponing this a couple of months?
As others have pointed out, you made a typo.
PHP 5.6 goes into 'security fixes only' on 28th August 2016, next year.
Its end of life is currently planned for 28th August 2017.
That means 5.6 EOL is 20 months and 11 days away. That's more than one
and a half years, it should be enough time to upgrade.
But with that said, there may be problems. Obviously, a lot of people
are still not using 5.6 or 5.5, even if they are unsupported. And while
7.0.0 might be out now, not everything supports it yet. There will be
other factors, too, which would make it difficult to upgrade within that
time period.
However, I'm not sure if extending the release date now is the best
idea. 7.0.0 has only been out for four days. We don't know where the
ecosystem will be in August 2017 or how many people will have migrated.
At this stage, I'm not sure we can assess whether we need an extension.
Furthermore, postponing EOL now means reduced pressure to upgrade to 7.
If people feel they do not have to move any time soon, perhaps they won't.
So, I wonder if it would not be better to wait until nearer the
deadline, and see if we need an extension then?
Thanks!
--
Andrea Faulds
http://ajf.me/
So, I wonder if it would not be better to wait until nearer the deadline,
and see if we need an extension then?
This is exactly the strategy that at least a few others in this thread
aside from myself are advocating against. Please let's just pick an
EOL date and stick to it. By planning to re-evaluate in one year that
inherently means that the community can drag the migration because
they know we are going to re-evaluate.
Am 07.12.2015 um 15:25 schrieb Levi Morrison:
So, I wonder if it would not be better to wait until nearer the deadline,
and see if we need an extension then?This is exactly the strategy that at least a few others in this thread
aside from myself are advocating against. Please let's just pick an
EOL date and stick to it. By planning to re-evaluate in one year that
inherently means that the community can drag the migration because
they know we are going to re-evaluate.
Exactly. We need a fixed EOL date and we need it now. And before this
thread started we had one: August 2017.
Sebastian Bergmann wrote on 07/12/2015 14:28:
Exactly. We need a fixed EOL date and we need it now. And before this
thread started we had one: August 2017.
To be fair, it wouldn't have taken a psychic to predict that this would
be at least discussed. Until now, there has never actually been a major
version since the release process RFC passed, and it's not at all
unreasonable to guess a special case might apply.
Even if there's consensus that no extension is required, I think an RFC
formally asserting that would be the only way to stop speculation.
Andrea Faulds wrote on 07/12/2015 14:16:
Furthermore, postponing EOL now means reduced pressure to upgrade to
- If people feel they do not have to move any time soon, perhaps they
won't.So, I wonder if it would not be better to wait until nearer the
deadline, and see if we need an extension then?
The problem is, that the genie's out of the bottle - there's been a
public discussion that the EOL might be extended (and realistically it
was always possible it would be proposed), so just "wait and see" is the
worst of both worlds: those wanting certainty don't get it, while those
who want to drag their feet can hope that the decision will go their way
in the end (a potentially self-fulfilling prophecy, if everyone waits
for someone else to jump).
There may be value in delaying a final decision, but we need to at least
make some decisions about the decision:
- If not now, when is the right time to decide? A month before the
standard deadline is not sensible, because it leads to uncertainty and
confusion. Maybe at the end of Full Support we decide the length of the
Security Support? Or maybe just give 7.0 a few months to "bed in"? - On what factors will the decision be based? If the reason to delay the
decision is lack of information, what information are we planning to
use? Are there metrics we can use to make a more objective decision?
Regards,
Rowan Collins
[IMSoP]
Rowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective decision?
Come to think, this works the other way as well: if we do make a
decision now, are there factors that would allow the question to be
reopened? Again, to have any trust in the announced date, people would
need to know what these were - if the decision is "probably August
2017", then that would be no decision at all.
Rowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective decision?Come to think, this works the other way as well: if we do make a
decision now, are there factors that would allow the question to be
reopened? Again, to have any trust in the announced date, people would
need to know what these were - if the decision is "probably August
2017", then that would be no decision at all.
At the current time August 2017 is more than reasonable. That some
distributions produce their own LTS versions, which for example PHP5.4
has become, just passes the onus to the publisher to act if some serious
security problem arises post that date. The PHP developers have already
passed the buck, but I have no doubt if something serious came up which
needed help from PHP developers they would help out? Certainly my PHP5.4
distribution still sees security related updates even today.
The point here is that people reliant on older versions of PHP are not
doing anything wrong, but rather that the official support for that may
not be via PHP direct. I doubt that PHP5.6 will be an LTS candidate in
any case, but we need a version of PHP7.0 well bedded in before it can
be leap frogged and that will hopefully be the situation by August 2016.
--
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
This is the current official timeline
http://php.net/supported-versions.php
I personally think it is long enough and would actually suggestion
shortening it (2016, not 2017). Extended the timeline would only further
influence people not to upgrade, as an excuse that it was still supported.
Rowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective decision?Come to think, this works the other way as well: if we do make a
decision now, are there factors that would allow the question to be
reopened? Again, to have any trust in the announced date, people would
need to know what these were - if the decision is "probably August
2017", then that would be no decision at all.At the current time August 2017 is more than reasonable. That some
distributions produce their own LTS versions, which for example PHP5.4
has become, just passes the onus to the publisher to act if some serious
security problem arises post that date. The PHP developers have already
passed the buck, but I have no doubt if something serious came up which
needed help from PHP developers they would help out? Certainly my PHP5.4
distribution still sees security related updates even today.The point here is that people reliant on older versions of PHP are not
doing anything wrong, but rather that the official support for that may
not be via PHP direct. I doubt that PHP5.6 will be an LTS candidate in
any case, but we need a version of PHP7.0 well bedded in before it can
be leap frogged and that will hopefully be the situation by August 2016.--
Lester Caine - G8HFLContact - 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
-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Monday, December 07, 2015 4:42 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycleRowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective
decision?Come to think, this works the other way as well: if we do make a
decision
now, are there factors that would allow the question to be reopened?
Again,
to have any trust in the announced date, people would need to know what
these were - if the decision is "probably August 2017", then that would
be no
decision at all.
It's always possible to submit another RFC to alter the end date, even if
we decide about one now. But I do think it'll send a different message -
that we think it's going to take extraordinary circumstances for us to
change the decision - vs. us saying "we'll wait and see", which at least I
would interpret as "they'll probably delay it".
Zeev
2015-12-07 17:11 GMT+02:00 Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Monday, December 07, 2015 4:42 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycleRowan Collins wrote on 07/12/2015 14:35:
- On what factors will the decision be based? If the reason to delay
the decision is lack of information, what information are we planning
to use? Are there metrics we can use to make a more objective
decision?Come to think, this works the other way as well: if we do make a
decision
now, are there factors that would allow the question to be reopened?
Again,
to have any trust in the announced date, people would need to know what
these were - if the decision is "probably August 2017", then that would
be no
decision at all.It's always possible to submit another RFC to alter the end date, even if
we decide about one now. But I do think it'll send a different message -
that we think it's going to take extraordinary circumstances for us to
change the decision - vs. us saying "we'll wait and see", which at least I
would interpret as "they'll probably delay it".Zeev
--
According to PHP release RFC - the date is already set. To extend support
for 5.6 you actually now need an RFC. Without the RFC any decision made by
anybody in that regard is invalid and irrelevant.
RFC or didn't happen.
Just to be clear people do not forget what they actually voted on and that
they have to stick to a process to make decisions.
-----Original Message-----
From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
Sent: Monday, December 07, 2015 5:52 PM
To: Zeev Suraski
Cc: Rowan Collins; PHP internals
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycleAccording to PHP release RFC - the date is already set. To extend support
for
5.6 you actually now need an RFC. Without the RFC any decision made by
anybody in that regard is invalid and irrelevant.
I already said yesterday that I'm going to work on an RFC, and I'm almost
done creating an initial draft for discussion.
Zeev
Den 2015-12-07 kl. 16:57, skrev Zeev Suraski:
-----Original Message-----
From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
Sent: Monday, December 07, 2015 5:52 PM
To: Zeev Suraski
Cc: Rowan Collins; PHP internals
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycleAccording to PHP release RFC - the date is already set. To extend support
for
5.6 you actually now need an RFC. Without the RFC any decision made by
anybody in that regard is invalid and irrelevant.
I already said yesterday that I'm going to work on an RFC, and I'm almost
done creating an initial draft for discussion.Zeev
Look forward reading it. Would it be a good idea to list different
incentives
for upgrading to PHP 7 and how important they are? Personally I'm not sure
that having prolonged 5.6 support is a big hindrance for PHP 7 upgrading.
Regards //Björn
Zeev Suraski wrote on 07/12/2015 15:11:
It's always possible to submit another RFC to alter the end date, even if
we decide about one now. But I do think it'll send a different message -
that we think it's going to take extraordinary circumstances for us to
change the decision - vs. us saying "we'll wait and see", which at least I
would interpret as "they'll probably delay it".
Yeah, that's absolutely my view. As with the 7.0 timeline and 5.7
(non-)existence, a formal RFC stating the position ends speculation and
allows everyone to make clear plans.
If there is a strong view that more evidence will be available in 6
months time, a short RFC now stating the date and criteria for a final
decision will allow us to short-cut part of the discussion next time.
But unless someone can name the specific information they're waiting
for, it's no easier to name the decision date than the EOL date itself,
so we're better off just making a firm decision now.
Regards,
Rowan Collins
[IMSoP]
OS's (CentOS/Debian) for example do offer official upgrade paths via their
own repositories and 3rd party repositories. However has history has shown
extended support only extends the resistance to update those paths, Alain
Williams
While the PHP Development Team obviously cannot control the actions of
others, it can be influenced by making it clear path regarding when EOL
(end of life) is achieved.
On Mon, Dec 7, 2015 at 9:35 AM, Rowan Collins rowan.collins@gmail.com
wrote:
Andrea Faulds wrote on 07/12/2015 14:16:
Furthermore, postponing EOL now means reduced pressure to upgrade to 7.
If people feel they do not have to move any time soon, perhaps they won't.So, I wonder if it would not be better to wait until nearer the deadline,
and see if we need an extension then?The problem is, that the genie's out of the bottle - there's been a public
discussion that the EOL might be extended (and realistically it was
always possible it would be proposed), so just "wait and see" is the worst
of both worlds: those wanting certainty don't get it, while those who want
to drag their feet can hope that the decision will go their way in the end
(a potentially self-fulfilling prophecy, if everyone waits for someone else
to jump).There may be value in delaying a final decision, but we need to at least
make some decisions about the decision:
- If not now, when is the right time to decide? A month before the
standard deadline is not sensible, because it leads to uncertainty and
confusion. Maybe at the end of Full Support we decide the length of the
Security Support? Or maybe just give 7.0 a few months to "bed in"?- On what factors will the decision be based? If the reason to delay the
decision is lack of information, what information are we planning to use?
Are there metrics we can use to make a more objective decision?Regards,
Rowan Collins
[IMSoP]
Hi!
That means 5.6 EOL is 20 months and 11 days away. That's more than one
and a half years, it should be enough time to upgrade.
I'm not sure what you mean here by "should be". If you mean "if
everybody dropped everything right now and started only working on
upgrade to PHP 7 then they could make it in 20 months" - yes, it is
reasonably true. But nobody would do that. In fact, in many places base
version is still 5.3. Again, we can talk that people "should" do this
and "should" do that until we're blue in the face, but that's not going
to happen, whatever we talk about. Only one of the two things is going
to happen:
- People would run 5.x in 2017 as supported version and get the fixes.
- People would run 5.x in 2017 as unsupported version, get no fixes and
suffer from it.
However, I'm not sure if extending the release date now is the best
idea. 7.0.0 has only been out for four days. We don't know where the
ecosystem will be in August 2017 or how many people will have migrated.
At this stage, I'm not sure we can assess whether we need an extension.
We don't know that about 7.0, but it's not the first version we've
released. We know what happened with previous versions. So please tell
me, based on that past experience - does the scenario of "majority of
users are running 7.x in 2017" sound realistic?
Furthermore, postponing EOL now means reduced pressure to upgrade to 7.
Again, if you think people's decision to upgrade significantly depends
on that, I think you are deluding yourself. We have tons of "pressure"
to upgrade from EOLed 5.x versions. We still got majority of people
running them, and more sites running 5.2 than 5.6, judging by
http://w3techs.com/technologies/details/pl-php/5/all
--
Stas Malyshev
smalyshev@gmail.com
I'm not sure what you mean here by "should be". If you mean "if
everybody dropped everything right now and started only working on
upgrade to PHP 7 then they could make it in 20 months" - yes, it is
reasonably true. But nobody would do that. In fact, in many places base
version is still 5.3. Again, we can talk that people "should" do this
and "should" do that until we're blue in the face, but that's not going
to happen, whatever we talk about. Only one of the two things is going
to happen:
- People would run 5.x in 2017 as supported version and get the fixes.
- People would run 5.x in 2017 as unsupported version, get no fixes and
suffer from it.
From my own perspective, the question is if people actually need to
update from PHP5.3 TO 5.6. Processing 5.2 to 5.3 and up to 5.4 is still
the sensible upgrade path and it's just as easy THEN upgrading straight
to PHP7 so currently I see any debate on 5.6 as academic since so few
people are currently 'stuck' with that version? There is little that
causes a normal roll over to the next version and the current user base
is already on that cycle?
--
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
Hi all,
Furthermore, postponing EOL now means reduced pressure to upgrade to 7.
Again, if you think people's decision to upgrade significantly depends
on that, I think you are deluding yourself. We have tons of "pressure"
to upgrade from EOLed 5.x versions. We still got majority of people
running them, and more sites running 5.2 than 5.6, judging by
http://w3techs.com/technologies/details/pl-php/5/all
Upgrading extensions from PHP 5.X to PHP 5.Y is easy or even does
not require any changes. Since upgrading extension modules to PHP 7
code base is not easy task for many people, giving more time for
upgrading makes sense. We don't know how many private extensions
are used in the wild.
http://w3techs.com/technologies/details/pl-php/5/all
This may be an evidence that there are many.
+1 for extending PHP 5.6 support.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
-----Original Message-----
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki
Sent: Tuesday, December 15, 2015 2:08 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.6 life cycleUpgrading extensions from PHP 5.X to PHP 5.Y is easy or even does not
require any changes. Since upgrading extension modules to PHP 7 code base
is not easy task for many people, giving more time for upgrading makes
sense. We don't know how many private extensions are used in the wild.
That's a good point that the RFC neglected to mention - I added it.
Thanks!
Zeev