Proposal: Version deprecation PSR (aka GoPHP PSR)
221 views
Skip to first unread message
Larry Garfield
Aug 20, 2015, 9:46:57 PM8/20/15
to php...@googlegroups.com
With cache (hopefully) wrapping up and PHP 7 RC 1 now released, I'd like
to direct the group's attention to another problem space where I believe
we can be useful. I've mentioned the idea privately to a number of
people and the response was cautiously positive, so let's see about
making it formal.
PHP 7 is going to be a big deal. However, we all know how poor version
upgrade timelines are for PHP. Supported PHP minor versions (5.5 and
5.6) currently account for a total of 13% of the install base (according
to w3techs[1]). If history is any guide, hosts will not be jumping to
PHP 7 all that quickly, which will hold back adoption, which will reduce
the incentive for hosts to upgrade to PHP 7...
We've been here before, of course. PHP 5 adoption had the same
chicken-and-egg problem for years, and what finally broke it was the
GoPHP 5 project: A collection of projects and hosts collectively saying
"we're sick as hell of PHP 4 and we're not going to take it anymore!"
That was an effective and successful campaign, but also a pain in the
butt. We really can and should do better than having a big (and
potentially politically contentious) marketing push every 5 years.
The problem is that few projects want to be the first to require a new
version, as it puts them at a competitive disadvantage. The larger the
project, the more that applies. Different projects have wildly
different stomachs for version-backlash, which makes coordination in the
Age of Composer(tm) even more of a challenge.
So let's fix that.
What I would propose is something similar to the security process PSR
that is being discussed: A version support "Best practices" doc that
projects could declare they follow. That would include, I expect, two
key things:
1) The amount of time after a new PHP release comes out that a project
has before it should fully support it (ie, not break on it).
2) The amount of time after a new PHP release is deprecated by Internals
that a project has before it gives up supporting it.
The latter is the more important point. Essentially, it becomes a
"rolling GoPHP 5"; collectively, projects agree (by opting into saying
"we follow the PSR-X schedule") that they will all drop support for old
PHP versions in roughly the same way and on the same schedule, which
means web hosts can reliably know when they can upgrade (because of the
first point) and when they realistically NEED to upgrade (or suddenly
become incompatible with lots of software).
That introduces a level of predictability for developers, sysadmins, and
hosts, and hopefully helps drive adoption of new PHP versions faster
than in the past so we can all start using the new cool toys sooner. :-)
I'm certain there's a lot more details to sort out than what I have
listed above. (Eg, do we handle major and minor releases differently.)
But that's what we would work out collectively during a draft phase.
Shall we?
--Larry Garfield
[1] http://w3techs.com/technologies/details/pl-php/5/all
to direct the group's attention to another problem space where I believe
we can be useful. I've mentioned the idea privately to a number of
people and the response was cautiously positive, so let's see about
making it formal.
PHP 7 is going to be a big deal. However, we all know how poor version
upgrade timelines are for PHP. Supported PHP minor versions (5.5 and
5.6) currently account for a total of 13% of the install base (according
to w3techs[1]). If history is any guide, hosts will not be jumping to
PHP 7 all that quickly, which will hold back adoption, which will reduce
the incentive for hosts to upgrade to PHP 7...
We've been here before, of course. PHP 5 adoption had the same
chicken-and-egg problem for years, and what finally broke it was the
GoPHP 5 project: A collection of projects and hosts collectively saying
"we're sick as hell of PHP 4 and we're not going to take it anymore!"
That was an effective and successful campaign, but also a pain in the
butt. We really can and should do better than having a big (and
potentially politically contentious) marketing push every 5 years.
The problem is that few projects want to be the first to require a new
version, as it puts them at a competitive disadvantage. The larger the
project, the more that applies. Different projects have wildly
different stomachs for version-backlash, which makes coordination in the
Age of Composer(tm) even more of a challenge.
So let's fix that.
What I would propose is something similar to the security process PSR
that is being discussed: A version support "Best practices" doc that
projects could declare they follow. That would include, I expect, two
key things:
1) The amount of time after a new PHP release comes out that a project
has before it should fully support it (ie, not break on it).
2) The amount of time after a new PHP release is deprecated by Internals
that a project has before it gives up supporting it.
The latter is the more important point. Essentially, it becomes a
"rolling GoPHP 5"; collectively, projects agree (by opting into saying
"we follow the PSR-X schedule") that they will all drop support for old
PHP versions in roughly the same way and on the same schedule, which
means web hosts can reliably know when they can upgrade (because of the
first point) and when they realistically NEED to upgrade (or suddenly
become incompatible with lots of software).
That introduces a level of predictability for developers, sysadmins, and
hosts, and hopefully helps drive adoption of new PHP versions faster
than in the past so we can all start using the new cool toys sooner. :-)
I'm certain there's a lot more details to sort out than what I have
listed above. (Eg, do we handle major and minor releases differently.)
But that's what we would work out collectively during a draft phase.
Shall we?
--Larry Garfield
[1] http://w3techs.com/technologies/details/pl-php/5/all
Christopher Pitt
Aug 20, 2015, 11:12:20 PM8/20/15
to PHP Framework Interoperability Group
That's an interesting idea. Could it conflict with SemVer + LTS?
Sam Minnée
Aug 21, 2015, 12:47:46 AM8/21/15
to PHP Framework Interoperability Group
If the 2nd point as refined to something like this, both semver and LTS should be okay:
[X time] after PHP Internals have dropped support of a PHP minor release, any subsequent major release of a package complying with this PSR will exclude support for that PHP minor release.
It might be worth considering if some of the expectations of SemVer are explicitly pulled into a PSR such as this. In particular, that support for PHP versions would only be dropped in a major version increment.
On Fri, 21 Aug 2015 at 15:12 Christopher Pitt <cgp...@gmail.com> wrote:
That's an interesting idea. Could it conflict with SemVer + LTS?
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ad7fdaa2-ab6f-4673-a626-f0efb7b76e87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Larry Garfield
Aug 21, 2015, 1:03:25 AM8/21/15
to php...@googlegroups.com
I think in practice we'd implicitly end
up defining semver, if only because that's what people will think
of if we refer to major or minor releases. Again, the language
around that would be very important but also something we'd work
out during draft.
I think the most important question is: Supposing such a PSR were created and didn't suck, would your project be willing to adopt it and follow it?
--Larry Garfield
I think the most important question is: Supposing such a PSR were created and didn't suck, would your project be willing to adopt it and follow it?
--Larry Garfield
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAD%3DSCN455sb9-ZYX-Fm2%3D%3DYzkBcaOOZOSkVgpYmo5ptaq2Vmfw%40mail.gmail.com.
Korvin Szanto
Aug 21, 2015, 1:10:52 AM8/21/15
to php...@googlegroups.com
I think it may be difficult to adopt for many projects, but it's something that is worth doing.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55D6B116.2070409%40garfieldtech.com.
Michael Johnson
Aug 21, 2015, 1:18:31 AM8/21/15
to php...@googlegroups.com
From the standpoint of utilizing projects in a commercial setting (and also in personal projects), if a project supported such a PSR I'd be more likely to use it. It tells me the project is dedicated to not stagnating. And that's one of the first things I check for when I'm considering using a library or framework.
Michael
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55D6B116.2070409%40garfieldtech.com.
Korvin Szanto
Aug 21, 2015, 2:26:18 PM8/21/15
to PHP Framework Interoperability Group
What I would propose is something similar to the security process PSR
that is being discussed: A version support "Best practices" doc that
projects could declare they follow. That would include, I expect, two
key things:
1) The amount of time after a new PHP release comes out that a project
has before it should fully support it (ie, not break on it).
This point is going to be difficult to agree to, as a project with a limited workforce we always work to support new versions before they are released but agreeing to do an unknowable amount of work for php versions that don't exist yet is a non-starter. Maybe we should spin this off into its own proposal?
2) The amount of time after a new PHP release is deprecated by Internals
that a project has before it gives up supporting it.
Now we're getting somewhere, are we talking about when the version is EOL, or when internals drops active support? The former is interesting and definitely where we'd like to be if we could get the hosting market share to support non-EOL versions sooner. The latter would be pretty difficult for us to agree to as we'd face losing a large portion of our potential market share.
One thought that comes to mind is that wordpress - a company that is partially funded by EIG (Bluehost, HostGator, Arvixe, and more)[1] - currently supports PHP 5.2.4 and is unlikely to agree to this. That could make it much easier for EIG to remain on EOL PHP versions and cause trouble for competition.
If we were to agree to this, we would likely need some level of official buy in from hosts including EIG to be sure that we can remain competitive in the space that we live.
We have some ins at EIG and would be happy to do some introductions, it'd also be cool if we could have a google hangout with some of the major players in the hosted space and talk about what this might mean strategically as well as practically.
Best wishes,
Korvin - concrete5
Larry Garfield
Aug 21, 2015, 3:00:07 PM8/21/15
to php...@googlegroups.com
On 8/21/15 1:26 PM, Korvin Szanto wrote:
>
> What I would propose is something similar to the security process PSR
> that is being discussed: A version support "Best practices" doc that
> projects could declare they follow. That would include, I expect,
> two
> key things:
>
>
> 1) The amount of time after a new PHP release comes out that a
> project
> has before it should fully support it (ie, not break on it).
>
>
> This point is going to be difficult to agree to, as a project with a
> limited workforce we always work to support new versions before they
> are released but agreeing to do an unknowable amount of work for php
> versions that don't exist yet is a non-starter. Maybe we should spin
> this off into its own proposal?
I'm hesitant to split this off. The idea here is to provide a common
>
> What I would propose is something similar to the security process PSR
> that is being discussed: A version support "Best practices" doc that
> projects could declare they follow. That would include, I expect,
> two
> key things:
>
>
> 1) The amount of time after a new PHP release comes out that a
> project
> has before it should fully support it (ie, not break on it).
>
>
> This point is going to be difficult to agree to, as a project with a
> limited workforce we always work to support new versions before they
> are released but agreeing to do an unknowable amount of work for php
> versions that don't exist yet is a non-starter. Maybe we should spin
> this off into its own proposal?
sliding window, so that hosts can know when they are safe to upgrade.
Splitting it up into pieces doesn't seem like it would be conducive
toward that effort. Of course, since there's no actual enforcement
power we have it's not like we can stop anyone from saying "we only do
part 2 of PSR-X".
> 2) The amount of time after a new PHP release is deprecated by
> Internals
> that a project has before it gives up supporting it.
>
>
> Now we're getting somewhere, are we talking about when the version is
> EOL, or when internals drops active support? The former is interesting
> and definitely where we'd like to be if we could get the hosting
> market share to support non-EOL versions sooner. The latter would be
> pretty difficult for us to agree to as we'd face losing a large
> portion of our potential market share.
to a particular timeframe, and we may want to give projects wiggle
room. Eg, there's nothing wrong with releasing a 5.6-requiring project
today. But projects should not be spending effort today making sure
their code runs on 5.3. (If it happens coincidentally, whatev.) In
practice, I expect it would be something like "projects will make no
effort to support a PHP minor version that is out of support for X
months/years or longer", for some to-be-determined value of X. By
fixing it to a calendar, rather than marketshare percentages, we can
influence what the marketshare percentages are of PHP versions.
The underlying goal here, as it was for GoPHP5, is that most projects
are afraid that if they drop support for an older PHP version before
anyone else does, they lose market share because everyone on those old
servers will stop using them, rather than upgrade their server. But if
a whole lot of projects say it at the same time, that puts market
pressure on those sysadmins to keep up or it's not one project that they
can't run anymore, it's all of them.
It's a prisoner's dilemma situation. The idea of this PSR is an easy
way for projects to communicate that they're taking the "cooperate"
option, and defining what that option means. :-) Hopefully, no one loses
market share as a result.
> One thought that comes to mind is that wordpress - a company that is
> partially funded by EIG (Bluehost, HostGator, Arvixe, and more)[1] -
> currently supports PHP 5.2.4 and is unlikely to agree to this. That
> could make it much easier for EIG to remain on EOL PHP versions and
> cause trouble for competition.
> If we were to agree to this, we would likely need some level of
> official buy in from hosts including EIG to be sure that we can remain
> competitive in the space that we live.
> We have some ins at EIG and would be happy to do some introductions,
> it'd also be cool if we could have a google hangout with some of the
> major players in the hosted space and talk about what this might mean
> strategically as well as practically.
would be good to talk to some of them.
As for Wordpress, Matt Mullenweg was actively and publicly hostile to
GoPHP5 so I would expect no involvement from them, nor would I bother
soliciting it. They're doing their own thing, fine, whatever; They
ignore us, I'll ignore them. :-)
That said, while WP does keep BC with ancient PHP versions they do, as I
understand it, make a concerted effort to support new versions. I would
be very surprised if the next point release of Wordpress doesn't run on
PHP 7 just fine. So at worst, hosts that ignore projects adopting this
PSR would be limiting themselves to being Wordpress-only hosts. So it
goes. *shrug*
--
--Larry Garfield
Aaron Jorbin
Aug 21, 2015, 3:09:41 PM8/21/15
to php...@googlegroups.com
A few small things:
1) WordPress the trademark is owned by the WordPress Foundation and WordPress the software is built by a large community. There is no company that is WordPress and thus there is no company that could be funded by EIG.
2) Members of the WordPress community have been actively working with hosts to encourage them to upgrade to more modern versions of PHP. This effort is ongoing.
3) As of version 4.3 (released earlier this week) WordPress runs fine on PHP7. The automated tests have been passing swimmingly, I've been running a site on nightly PHP and nightly WordPress builds for almost a month and haven't run into any issues. Formal support will likely come in the first release following PHP7's full release, though that in part depends on timing of both releases.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55D77530.8090306%40garfieldtech.com.
Larry Garfield
Aug 21, 2015, 3:13:58 PM8/21/15
to php...@googlegroups.com
On 8/21/15 2:09 PM, Aaron Jorbin wrote:
> A few small things:
>
> 1) WordPress the trademark is owned by the WordPress Foundation and
> WordPress the software is built by a large community. There is no
> company that is WordPress and thus there is no company that could be
> funded by EIG.
> 2) Members of the WordPress community have been actively working with
> hosts to encourage them to upgrade to more modern versions of PHP.
> This effort is ongoing.
Great, please keep up the effort!
> A few small things:
>
> 1) WordPress the trademark is owned by the WordPress Foundation and
> WordPress the software is built by a large community. There is no
> company that is WordPress and thus there is no company that could be
> funded by EIG.
> 2) Members of the WordPress community have been actively working with
> hosts to encourage them to upgrade to more modern versions of PHP.
> This effort is ongoing.
> 3) As of version 4.3 (released earlier this week) WordPress runs fine
> on PHP7. The automated tests have been passing swimmingly, I've been
> running a site on nightly PHP and nightly WordPress builds for almost
> a month and haven't run into any issues. Formal support will likely
> come in the first release following PHP7's full release, though that
> in part depends on timing of both releases.
--
--Larry Garfield
Korvin Szanto
Aug 21, 2015, 3:19:15 PM8/21/15
to php...@googlegroups.com
On Fri, Aug 21, 2015 at 12:09 PM Aaron Jorbin <aa...@jorb.in> wrote:
A few small things:1) WordPress the trademark is owned by the WordPress Foundation and WordPress the software is built by a large community. There is no company that is WordPress and thus there is no company that could be funded by EIG.
I don't mean to suggest any collusion is happening, just that there is a potential for conflict of interest.
2) Members of the WordPress community have been actively working with hosts to encourage them to upgrade to more modern versions of PHP. This effort is ongoing.
This is my understanding as well, that's great to hear!
Michael Cullum (phpBB)
Aug 21, 2015, 9:10:45 PM8/21/15
to PHP Framework Interoperability Group
After a discussion on IRC I think that there is potential here to split it this into three concerns:
1) We will ensure we have support for new php versions by x time after it's release (As Larry's original proposal)
2) We will ensure we continue to support php version for x time from it's release
3) We will have scrapped php support by x time
Concern 2 & 3 could be described as a range of time in which support will be dropped for that php version.
Concern 1 is a promise to have support for a php version in a release of some descript (x, x.y or x.y.z) within that amount of time after a release (e.g. 6 months after initial release).
Concern 2 is a promise to keep support for a php version for at least a certain an amount of time (e.g. 2 years after initial release).
Concern 3 is a threat that by this date, support for that php version will have been dropped and minimum requirement raised (e.g. 4 years after PHP EOL).
Having a range also means we are not dictating release cycles or exactly when support must be dropped, whilst still having that threat to web hosts (3), promise for web hosts (1) and promise for consumers (2).
I might also add that I think when it comes to the draft stage we would have to look at how we can have different time scales for major (x) releases and minor (x.y) releases as something like PHP 7 might require more time to do a release that fully supports it, compared to 5.x releases which are relatively seamless. We should also then perhaps consider supporting the last x.y before x+1 for longer as people might be more cautious to switch (A lot of people will wait to switch and go to PHP 7.1 instead of 7.0 as 7.0 for obvious reasons won't be amazingly stable).
+1 to the over arching concept.
(Please see inline comment below also)
--
Michael C
phpBB
On Friday, 21 August 2015 20:09:41 UTC+1, Aaron Jorbin wrote:
A few small things:1) WordPress the trademark is owned by the WordPress Foundation and WordPress the software is built by a large community. There is no company that is WordPress and thus there is no company that could be funded by EIG.
What Korvin was referring to is that they pay the WordPress Foundation for services rendered, more specifically advertising on your hosting page (https://wordpress.org/hosting/). Also EIG have invested in Automattic Inc. which, whilst separate and is just granted use of the Wordpress trademark, shares much of it's project leadership with WordPress. However, this applies to a few members of the FIG though, not just Wordpress, and I think we should look upon these close relations as an opportunity to co-operate, not necessarily as a negative conflict of interest.
Larry Garfield
Aug 23, 2015, 12:04:56 PM8/23/15
to php...@googlegroups.com
Yes, those 3 timestamps seem like the
key. And balancing them is, of course, the goal.
Let me cut to the chase: If I put together a more formal proposal for this PSR and brought it to an entrance vote:
1) Who would be willing to Sponsor/Coordinate?
2) Which voting reps would be willing to support it in an Entrance Vote?
So far we still haven't heard from most voting reps, although the feedback I'm hearing is mostly-positive-with-some-resourcing-concerns. (Hopefully we can address those during Draft phase.)
--Larry Garfield
Let me cut to the chase: If I put together a more formal proposal for this PSR and brought it to an entrance vote:
1) Who would be willing to Sponsor/Coordinate?
2) Which voting reps would be willing to support it in an Entrance Vote?
So far we still haven't heard from most voting reps, although the feedback I'm hearing is mostly-positive-with-some-resourcing-concerns. (Hopefully we can address those during Draft phase.)
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/69b81c49-e6ec-4157-85ed-ba914968b770%40googlegroups.com.
Jeroen De Dauw
Aug 23, 2015, 5:52:57 PM8/23/15
to PHP Framework Interoperability Group
+1 to the concept
Korvin Szanto
Aug 23, 2015, 6:08:13 PM8/23/15
to php...@googlegroups.com
1) Who would be willing to Sponsor/Coordinate?
I'd be glad to sponsor this.
Jacob Santos
Aug 25, 2015, 12:37:07 PM8/25/15
to PHP Framework Interoperability Group
A few questions. I am not saying that there shouldn't be a PSR and given that I'm not a member of a group associated with or a member of FIG, then I don't have any vote on the matter. I am neutral and indifferent on the topic.
1. Has anyone done any survey(s) of hosting companies, formal or informal as to whether they upgraded to PHP5 because of GoPHP5? If so, what percentage of hosting companies did so?
2. What influence did GoPHP5 have on hosts upgrading to PHP5?
3. What influence did other factors account for hosts upgrading to PHP5?
I believe you are making the claim that GoPHP5 had due influence on hosts to upgrade to PHP5. I doubt the veracity of the claim. Not simply that WordPress proves at least one counter to the claim.
1. Automattic or WordPress Foundation working with hosts probably had more direct influence than projects committing Seppuku in the service of some ideal that may or may not factor into some long term goal.
2. WordPress dropping minimum requirement for past PHP versions when actual PHP usage statistics warrants dropping past PHP versions. Granted, it was subjective. Do you drop when 1% or 10% or 20%? It is possible that GoPHP5 accounted for some of the drop or it could have been those that talked with hosts, whether Automattic or WordPress Foundation or other foundations.
What about LTS support with Linux distros supporting PHP7?
The company I am with won't be upgrading to PHP7 regardless of project minimum requirements until the Linux LTS distro supports PHP7. The earliest will be 2016, providing the distro adds PHP7 that soon. If not, then it won't be until 2018. It could be that at some point during that time frame, the LTS may provide support for PHP7, but history suggests that PHP7 won't be stable until at least 7.0.3 and won't be LTS usable until 7.0.6-9+. Given the amount of changes to the PHP engine. It is my personal opinion that PHP won't be stable until PHP 7.1 or 7.2, if you want to use PHP5 as a reference.
It is true that those on shared or managed hosts, may not rely on LTS support and may upgrade to PHP7 on their own time frame (Dreamhost). That is not the point of this question.
What about upgrade paths for companies with dedicated hosts?
Will individuals or company IT actually upgrade PHP to upgrade to the latest project version or simply stick with the latest project version that works with their PHP version?
Some will, the adoption curve suggests as much.
Anthony Ferrara
Aug 25, 2015, 1:44:00 PM8/25/15
to php...@googlegroups.com
Jacob,
On Tue, Aug 25, 2015 at 12:37 PM, Jacob Santos <jacob...@dragonu.net> wrote:
> A few questions. I am not saying that there shouldn't be a PSR and given
> that I'm not a member of a group associated with or a member of FIG, then I
> don't have any vote on the matter. I am neutral and indifferent on the
> topic.
>
> 1. Has anyone done any survey(s) of hosting companies, formal or informal as
> to whether they upgraded to PHP5 because of GoPHP5? If so, what percentage
> of hosting companies did so?
Yes.
A "percentage of hosts" is really hard to calculate, because that
implies we know how many hosts exist. We can simply look at server
numbers. The fact of the matter is that prior to GoPHP5, the number of
servers supporting 5.x was single digit percentage of servers. 8
months later, it was well over 50%.
> 2. What influence did GoPHP5 have on hosts upgrading to PHP5?
Many hosts signed up to be a part of GoPHP5. Many others did so out of
pressure from their clients.
> 3. What influence did other factors account for hosts upgrading to PHP5?
Really hard to know. Some projects (Like Symfony and Propel) went 5.0
only long before GoPHP5. There were performance and security benefits
to upgrading.
The exact infulence is unknown. But the correlation is huge.
> I believe you are making the claim that GoPHP5 had due influence on hosts to
> upgrade to PHP5. I doubt the veracity of the claim. Not simply that
> WordPress proves at least one counter to the claim.
>
> 1. Automattic or WordPress Foundation working with hosts probably had more
> direct influence than projects committing Seppuku in the service of some
> ideal that may or may not factor into some long term goal.
Totally disagree here. The past has shown this. The current support of
5.2 hasn't changed significantly in the past several years (where
Automattic/WordPress has been doing campaigning). With GoPHP5, 4.x
dropped market share from >80% to under 40% within about 8 months.
The fact is that WP/Automattic had nothing to do with PHP 5 adoption
in the early years. They may be moving the bar today on 5.2, but
that's because they are the only reason it's still a problem. Everyone
else (with few exceptions) have moved past that point.
Incidentally, there was a lot of fear in projects that they would be
committing "Seppuku". Yet it didn't happen to even a single project in
that list. Not something that you can say about those who didn't come
along for the GoPHP5 movement.
> 2. WordPress dropping minimum requirement for past PHP versions when actual
> PHP usage statistics warrants dropping past PHP versions. Granted, it was
> subjective. Do you drop when 1% or 10% or 20%? It is possible that GoPHP5
> accounted for some of the drop or it could have been those that talked with
> hosts, whether Automattic or WordPress Foundation or other foundations.
You can lead, or you can follow. WP has chosen to follow the hosts.
That doesn't mean that it's wrong to want to lead them. You can't
aruge that because both sides have seen amazing success doing it.
Even parts of WP's own community disagrees with the practice. Some
like it, but many in the WP community have been actively speaking out
against it. The hard line is being drawn by the leadership. But that
doesn't mean it's the opinion of the entire community...
> What about LTS support with Linux distros supporting PHP7?
>
> The company I am with won't be upgrading to PHP7 regardless of project
> minimum requirements until the Linux LTS distro supports PHP7. The earliest
> will be 2016, providing the distro adds PHP7 that soon. If not, then it
> won't be until 2018. It could be that at some point during that time frame,
> the LTS may provide support for PHP7, but history suggests that PHP7 won't
> be stable until at least 7.0.3 and won't be LTS usable until 7.0.6-9+. Given
> the amount of changes to the PHP engine. It is my personal opinion that PHP
> won't be stable until PHP 7.1 or 7.2, if you want to use PHP5 as a
> reference.
The irony of that is that these LTS releases actually make the
security problem FAR more difficult to solve. Because tooling that
enables security to be a userland concern is introduced over time.
Look at Debian, their distro of 5.3.3, which is supported by LTS
**still contains a buggy bcrypt implementation**. Because the fix is
seen as a "feature", and as such you can't benefit from it.
> It is true that those on shared or managed hosts, may not rely on LTS
> support and may upgrade to PHP7 on their own time frame (Dreamhost). That is
> not the point of this question.
>
> What about upgrade paths for companies with dedicated hosts?
>
> Will individuals or company IT actually upgrade PHP to upgrade to the latest
> project version or simply stick with the latest project version that works
> with their PHP version?
>
> Some will, the adoption curve suggests as much.
PHP 4->5 was a big change. 5.2->5.3 was a moderate change.
5.3->5.4 was small
5.4->5.5 was small
5.5->5.6 was tiny
5.6->7 is quite small.
Aside from a few reserved words, the vast majority of code "will just
work". We've actually worked exceptionally hard to do that. We're
trying to make the upgrade path as simple as possible.
This means that the adoption curve will be impacted more by
leadership. Previously the adoption rates have been largely governed
by the amount of manhours needed to actually execute the upgrade. With
7, it's simply convincing teams and admins to "flip the switch". The
majority of code should work out of the box.
My $0.02 at least
Anthony
On Tue, Aug 25, 2015 at 12:37 PM, Jacob Santos <jacob...@dragonu.net> wrote:
> A few questions. I am not saying that there shouldn't be a PSR and given
> that I'm not a member of a group associated with or a member of FIG, then I
> don't have any vote on the matter. I am neutral and indifferent on the
> topic.
>
> 1. Has anyone done any survey(s) of hosting companies, formal or informal as
> to whether they upgraded to PHP5 because of GoPHP5? If so, what percentage
> of hosting companies did so?
A "percentage of hosts" is really hard to calculate, because that
implies we know how many hosts exist. We can simply look at server
numbers. The fact of the matter is that prior to GoPHP5, the number of
servers supporting 5.x was single digit percentage of servers. 8
months later, it was well over 50%.
> 2. What influence did GoPHP5 have on hosts upgrading to PHP5?
pressure from their clients.
> 3. What influence did other factors account for hosts upgrading to PHP5?
only long before GoPHP5. There were performance and security benefits
to upgrading.
The exact infulence is unknown. But the correlation is huge.
> I believe you are making the claim that GoPHP5 had due influence on hosts to
> upgrade to PHP5. I doubt the veracity of the claim. Not simply that
> WordPress proves at least one counter to the claim.
>
> 1. Automattic or WordPress Foundation working with hosts probably had more
> direct influence than projects committing Seppuku in the service of some
> ideal that may or may not factor into some long term goal.
5.2 hasn't changed significantly in the past several years (where
Automattic/WordPress has been doing campaigning). With GoPHP5, 4.x
dropped market share from >80% to under 40% within about 8 months.
The fact is that WP/Automattic had nothing to do with PHP 5 adoption
in the early years. They may be moving the bar today on 5.2, but
that's because they are the only reason it's still a problem. Everyone
else (with few exceptions) have moved past that point.
Incidentally, there was a lot of fear in projects that they would be
committing "Seppuku". Yet it didn't happen to even a single project in
that list. Not something that you can say about those who didn't come
along for the GoPHP5 movement.
> 2. WordPress dropping minimum requirement for past PHP versions when actual
> PHP usage statistics warrants dropping past PHP versions. Granted, it was
> subjective. Do you drop when 1% or 10% or 20%? It is possible that GoPHP5
> accounted for some of the drop or it could have been those that talked with
> hosts, whether Automattic or WordPress Foundation or other foundations.
That doesn't mean that it's wrong to want to lead them. You can't
aruge that because both sides have seen amazing success doing it.
Even parts of WP's own community disagrees with the practice. Some
like it, but many in the WP community have been actively speaking out
against it. The hard line is being drawn by the leadership. But that
doesn't mean it's the opinion of the entire community...
> What about LTS support with Linux distros supporting PHP7?
>
> The company I am with won't be upgrading to PHP7 regardless of project
> minimum requirements until the Linux LTS distro supports PHP7. The earliest
> will be 2016, providing the distro adds PHP7 that soon. If not, then it
> won't be until 2018. It could be that at some point during that time frame,
> the LTS may provide support for PHP7, but history suggests that PHP7 won't
> be stable until at least 7.0.3 and won't be LTS usable until 7.0.6-9+. Given
> the amount of changes to the PHP engine. It is my personal opinion that PHP
> won't be stable until PHP 7.1 or 7.2, if you want to use PHP5 as a
> reference.
security problem FAR more difficult to solve. Because tooling that
enables security to be a userland concern is introduced over time.
Look at Debian, their distro of 5.3.3, which is supported by LTS
**still contains a buggy bcrypt implementation**. Because the fix is
seen as a "feature", and as such you can't benefit from it.
> It is true that those on shared or managed hosts, may not rely on LTS
> support and may upgrade to PHP7 on their own time frame (Dreamhost). That is
> not the point of this question.
>
> What about upgrade paths for companies with dedicated hosts?
>
> Will individuals or company IT actually upgrade PHP to upgrade to the latest
> project version or simply stick with the latest project version that works
> with their PHP version?
>
> Some will, the adoption curve suggests as much.
5.3->5.4 was small
5.4->5.5 was small
5.5->5.6 was tiny
5.6->7 is quite small.
Aside from a few reserved words, the vast majority of code "will just
work". We've actually worked exceptionally hard to do that. We're
trying to make the upgrade path as simple as possible.
This means that the adoption curve will be impacted more by
leadership. Previously the adoption rates have been largely governed
by the amount of manhours needed to actually execute the upgrade. With
7, it's simply convincing teams and admins to "flip the switch". The
majority of code should work out of the box.
My $0.02 at least
Anthony
Michael Cullum
Aug 25, 2015, 4:33:08 PM8/25/15
to PHP Framework Interoperability Group
I think linux distro php versions are an important point to consider when deciding on specific time frames in the draft phase however and we cannot just ignore them (Installation of PHP 5.6 on Ubuntu 14.04 requires ppa unless I'm missing a trick).
As previously stated, there is nothing wrong with us defining a different timespan for major releases (x) compared to (x.y) and I don't think this would be a bad idea. I'd say the difference in the upgrade path between x.y releases and x releases is enough to cause a longer time to update for compatibility, especially when considering larger web apps/frameworks (phpBB, Drupal, Wordpress, Symfony).
Anthony, something to consider is not just upgrade paths, but also the stability of versions. 7.0 is not going to be as stable as 5.6 for example due to the huge backend changes and the fact many extensions are having to almost rewrite due to huge internal API changes? I don't think we don't want to force people to update to it as quickly as we might for an x.y release.
Ryan Parman
Aug 25, 2015, 5:05:21 PM8/25/15
to Larry Garfield, php...@googlegroups.com
Food for thought:
My company is actively trying to move from PHP 5.4 → 5.6 for our legacy app, but known incompatibilities, poor legacy test coverage, and certain "old-timers" have caused me to spend the last 8 months trying to push this boulder uphill — just to get to 5.6. Why is the business trying to migrate? Because 5.4 goes EOL in a few weeks, and I’m the only person banging the upgrade drum and playing the “security” card. That, and we want to be able to use AWS SDK v3 and Guzzle v6 to improve our legacy app, but we can’t.
Now, I think a reasonable deprecation schedule is to follow PHP’s deprecation schedule, plus one version back (e.g., next month, packages cut off 5.3 support). IMO, it’s too soon to push for PHP 7 (despite its awesomeness + continued deficiencies), and it’s even less of the FIG’s business to push anything (remember: PSRs are “Recommendations", not “Standards”).
Then again, U.S. PCI compliance (for financially-related businesses) will be requiring nothing older than TLS 1.2 connections by June 2016. This means a minimum PHP version of 5.5.19 or 5.6.3 and cURL 1.0.1 to make the requests with a version of the PHP cURL extension that supports TLS 1.2. If you’re writing a package that targets these businesses, how do you guarantee deprecation timelines when outside forces dictate something different? And this is only one business industry. What about the countless others?
I might be inclined to support this if it were entirely optional (which all PSRs are, but people lost their g****mn minds over PSR-2 because some of us went around calling it a “Standard”).
If we could leave behind the “religious” zealotry that we encountered over PSR-2, and simply have a document that lists a schedule, that projects could point to when they don’t want to write their own, fine. But people need to understand that — for stability — we can’t all jump to PHP 7 on a whim. Nobody should be chastised for not migrating for reasons you don’t understand.
--
Ryan Parman
"At times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists." — Alistair Smith
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55D6830A.5080304%40garfieldtech.com.
Larry Garfield
Aug 25, 2015, 6:09:02 PM8/25/15
to php...@googlegroups.com
To answer a couple of points at once...
I have no idea what percentages were, but about a month after it launched GoPHP5 had around 100 participating projects and about 200 hosts. Participating hosts needed to already be offering PHP 5.2 by default for new accounts in order to be listed.
I suspect it was a lot of smaller hosts that were already on 5.2 and saw a good opportunity for free advertising, which we were happy to provide. (That was the point.) As Anthony noted, correlation doesn't prove causality but in this case it is very suggestive of it.
As far as Seppuku risks, that's the reason GoPHP5 was necessary. Everyone was worried that if they upped their requirements first, they would lose marketshare to everyone else. But by everyone moving at about the same time, it meant no project had to take the full brunt of the shift. This PSR has the same goal: If several dozen projects all say "we're dropping 5.5 on this schedule, 5.5 support on this schedule, and 5.6 on this schedule, etc.) then none of them is at serious risk of not being able to find supporting servers, because anyone running a server is going to have to stay up to date or risk not being able to run anything.
Prisoners Dilemma, where we agree to take the cooperate option rather than defect. :-) It's also nicer on hosts because they can plan their upgrade cycles around it, too.
I fully agree that we do not want to force people onto PHP 7 too quickly, and at the same time we shouldn't require that people support 5.5 if they want to use 5.6 or 7.0 features. (That would be counter-productive.)
Distro LTSs are an interesting problem space. As Anthony notes, they cause as much trouble as they resolve so I'm not sure if we want to make allowances for those. I'd rather keep it simple and fix to PHP's release schedule, not to who knows what Distro.
Korvin said he's willing to sponsor. Anyone willing to Coordinate? Cal, how about you? :-P
--Larry Garfield
I have no idea what percentages were, but about a month after it launched GoPHP5 had around 100 participating projects and about 200 hosts. Participating hosts needed to already be offering PHP 5.2 by default for new accounts in order to be listed.
I suspect it was a lot of smaller hosts that were already on 5.2 and saw a good opportunity for free advertising, which we were happy to provide. (That was the point.) As Anthony noted, correlation doesn't prove causality but in this case it is very suggestive of it.
As far as Seppuku risks, that's the reason GoPHP5 was necessary. Everyone was worried that if they upped their requirements first, they would lose marketshare to everyone else. But by everyone moving at about the same time, it meant no project had to take the full brunt of the shift. This PSR has the same goal: If several dozen projects all say "we're dropping 5.5 on this schedule, 5.5 support on this schedule, and 5.6 on this schedule, etc.) then none of them is at serious risk of not being able to find supporting servers, because anyone running a server is going to have to stay up to date or risk not being able to run anything.
Prisoners Dilemma, where we agree to take the cooperate option rather than defect. :-) It's also nicer on hosts because they can plan their upgrade cycles around it, too.
I fully agree that we do not want to force people onto PHP 7 too quickly, and at the same time we shouldn't require that people support 5.5 if they want to use 5.6 or 7.0 features. (That would be counter-productive.)
Distro LTSs are an interesting problem space. As Anthony notes, they cause as much trouble as they resolve so I'm not sure if we want to make allowances for those. I'd rather keep it simple and fix to PHP's release schedule, not to who knows what Distro.
Korvin said he's willing to sponsor. Anyone willing to Coordinate? Cal, how about you? :-P
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1dba6ab8-cbf4-4b96-b4cb-31ff14d1d120%40googlegroups.com.
Anthony Ferrara
Aug 26, 2015, 6:45:40 PM8/26/15
to php...@googlegroups.com, Larry Garfield
Ryan,
On Tue, Aug 25, 2015 at 5:05 PM, Ryan Parman <ry...@ryanparman.com> wrote:
> Food for thought:
>
> My company is actively trying to move from PHP 5.4 → 5.6 for our legacy app,
> but known incompatibilities, poor legacy test coverage, and certain
> "old-timers" have caused me to spend the last 8 months trying to push this
> boulder uphill — just to get to 5.6. Why is the business trying to migrate?
> Because 5.4 goes EOL in a few weeks, and I’m the only person banging the
> upgrade drum and playing the “security” card. That, and we want to be able
> to use AWS SDK v3 and Guzzle v6 to improve our legacy app, but we can’t.
>
> Now, I think a reasonable deprecation schedule is to follow PHP’s
> deprecation schedule, plus one version back (e.g., next month, packages cut
> off 5.3 support). IMO, it’s too soon to push for PHP 7 (despite its
> awesomeness + continued deficiencies), and it’s even less of the FIG’s
> business to push anything (remember: PSRs are “Recommendations", not
> “Standards”).
>
> Then again, U.S. PCI compliance (for financially-related businesses) will be
> requiring nothing older than TLS 1.2 connections by June 2016. This means a
> minimum PHP version of 5.5.19 or 5.6.3 and cURL 1.0.1 to make the requests
> with a version of the PHP cURL extension that supports TLS 1.2. If you’re
> writing a package that targets these businesses, how do you guarantee
> deprecation timelines when outside forces dictate something different? And
> this is only one business industry. What about the countless others?
Considering peer validation is broken in 5.5.x, 5.6.3 is going to be
required there...
> I might be inclined to support this if it were entirely optional (which all
> PSRs are, but people lost their g****mn minds over PSR-2 because some of us
> went around calling it a “Standard”).
>
> If we could leave behind the “religious” zealotry that we encountered over
> PSR-2, and simply have a document that lists a schedule, that projects could
> point to when they don’t want to write their own, fine. But people need to
> understand that — for stability — we can’t all jump to PHP 7 on a whim.
> Nobody should be chastised for not migrating for reasons you don’t
> understand.
Of course. My point in my reply was less that people should be forced
to upgrade as fast as possible, but more that the roadblocks and the
situation is very different from before. The reasons to not upgrade
are not nearly as strong as before. We're trying to make it easier to
move on as painlessly as possible.
If both sides can do that (we make it easy, projects encourage it),
then we won't run into the problem where we need to get religious
about upgrading, it'll just become natural...
My $0.04 at least...
Anthony
On Tue, Aug 25, 2015 at 5:05 PM, Ryan Parman <ry...@ryanparman.com> wrote:
> Food for thought:
>
> My company is actively trying to move from PHP 5.4 → 5.6 for our legacy app,
> but known incompatibilities, poor legacy test coverage, and certain
> "old-timers" have caused me to spend the last 8 months trying to push this
> boulder uphill — just to get to 5.6. Why is the business trying to migrate?
> Because 5.4 goes EOL in a few weeks, and I’m the only person banging the
> upgrade drum and playing the “security” card. That, and we want to be able
> to use AWS SDK v3 and Guzzle v6 to improve our legacy app, but we can’t.
>
> Now, I think a reasonable deprecation schedule is to follow PHP’s
> deprecation schedule, plus one version back (e.g., next month, packages cut
> off 5.3 support). IMO, it’s too soon to push for PHP 7 (despite its
> awesomeness + continued deficiencies), and it’s even less of the FIG’s
> business to push anything (remember: PSRs are “Recommendations", not
> “Standards”).
>
> Then again, U.S. PCI compliance (for financially-related businesses) will be
> requiring nothing older than TLS 1.2 connections by June 2016. This means a
> minimum PHP version of 5.5.19 or 5.6.3 and cURL 1.0.1 to make the requests
> with a version of the PHP cURL extension that supports TLS 1.2. If you’re
> writing a package that targets these businesses, how do you guarantee
> deprecation timelines when outside forces dictate something different? And
> this is only one business industry. What about the countless others?
required there...
> I might be inclined to support this if it were entirely optional (which all
> PSRs are, but people lost their g****mn minds over PSR-2 because some of us
> went around calling it a “Standard”).
>
> If we could leave behind the “religious” zealotry that we encountered over
> PSR-2, and simply have a document that lists a schedule, that projects could
> point to when they don’t want to write their own, fine. But people need to
> understand that — for stability — we can’t all jump to PHP 7 on a whim.
> Nobody should be chastised for not migrating for reasons you don’t
> understand.
to upgrade as fast as possible, but more that the roadblocks and the
situation is very different from before. The reasons to not upgrade
are not nearly as strong as before. We're trying to make it easier to
move on as painlessly as possible.
If both sides can do that (we make it easy, projects encourage it),
then we won't run into the problem where we need to get religious
about upgrading, it'll just become natural...
My $0.04 at least...
Anthony
Larry Garfield
Aug 27, 2015, 12:31:36 PM8/27/15
to php...@googlegroups.com
On 08/26/2015 05:45 PM, Anthony Ferrara wrote:
> If both sides can do that (we make it easy, projects encourage it),
> then we won't run into the problem where we need to get religious
> about upgrading, it'll just become natural...
>
> My $0.04 at least...
>
> Anthony
^^ THIS!
> If both sides can do that (we make it easy, projects encourage it),
> then we won't run into the problem where we need to get religious
> about upgrading, it'll just become natural...
>
> My $0.04 at least...
>
> Anthony
Still looking for a Coordinator...
--Larry Garfield
Dracony
Aug 27, 2015, 2:17:50 PM8/27/15
to PHP Framework Interoperability Group
Some difference and an actual problem here lies in there being little exclusive features in 7 that would justify dropping support for 5.4. The jump from 4 to 5 was huge in terms of PHP features and projects could easily justify not supporting 4. Now it seems that dropping support for say 5.5 would be hugely artificial for a project that doesnt rely on say anonymous classes. True, a project could state, that PHP 7 is the supported version although the code works fine on PHP 5.4 too. But such a statement would hugely undermine the push behind the move.
Apart from putting some PHP 7 specific features into the code ( e.g. the new type hinting) to force people to upgrade, I don't see this getting as much of a push as GoPHP5
Michael Cullum
Aug 27, 2015, 6:57:30 PM8/27/15
to PHP FIG
phpBB and I suspect other web apps have mechanisms to prevent installation on systems that don't match requirements and the library equivalent is requiring a php version in your composer.json. But I do see what you mean (saying a minimum requirement as opposed to it actually being a minimum requirement).
--
Thanks,
Michael Cullum
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/cdcc9055-55bc-4fb3-9836-d805bda770d4%40googlegroups.com.
Jan Schneider
Aug 28, 2015, 3:46:06 PM8/28/15
to php...@googlegroups.com
Zitat von Larry Garfield <la...@garfieldtech.com>:
of PHP is released, in any non-trivial PHP based project. But the
release date of PHP versions is not of any significant meaning in at
least mid-sized companies and organization, in my experience. What IS
important is the shipped minor PHP version in the large, commercially
supported Linux distributions.
IMO, and that's how we did it in Horde for the last 15 years, it's an
individual decision you have to make with any of your own major/minor
releases and the corresponding PHP major/minor versions at that time.
As a result, attaching the release schedule to PHP release dates
doesn't make any sense to us, and we won't be adopting such a PSR.
Jan.
--
Jan Schneider
The Horde Project
http://www.horde.org/
Reply all
Reply to author
Forward
0 new messages