[wp-trac] [WordPress Trac] #33381: Strategize the updating of minimum PHP version.

[WordPress Trac]

#33381: Strategize the updating of minimum PHP version.
-------------------------------------------------+-------------------------
 Reporter:  alexander.rohmann                    |       Owner:  jorbin
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
Component:  General                              |  Review
 Severity:  normal                               |     Version:
 Keywords:  needs-codex dev-feedback 2nd-        |  Resolution:
  opinion                                        |     Focuses:
-------------------------------------------------+-------------------------

Comment (by jdgrimes):

 I two more thoughts on this last night:

 1. Building docs and possibly adding a notice eventually is something that
 is going to need input from the UX team or whoever can help us do
 usertests. Sometimes it is hard for us to really know how a user is going
 to respond to something like that in real life. Non-devs will need to be
 heavily involved.
 2. As far as time based vs percentage based in terms of deciding when to
 update, I don't support an entirely percentage-based approach. Of course,
 the percentage does need to be taken into account, but I think that a time
 factor has to be there as well, and here is why. If we just say, for the
 sake of example, that we're going to drop support once a version reaches
 5% usage, then we are basically always going to be leaving approximately
 the last 5% of users on an unsupported version. Even if everybody is more
 proactive about staying up to date, that just means that we get to 5%
 quicker. Some people will still come in last, even if they aren't taking
 years to update. That's why there needs to be a deadline component. If we
 set a date 6 months or a year ahead of time, that gives everybody enough
 time that potentially when the deadline comes there is nobody still
 running that version. I realize that won't actually happen, but you get
 the general idea. A large number of that 5% is given a better chance of
 getting updated in time, probably by their hosts, and never even having to
 deal with this.

 So basically, I'd recommend something similar to @Sobak: once we approach
 5% (or whatever number), we should set a date 3 releases into the future.
 Maybe during that first release cycle, we are basically just giving hosts
 a chance to get their users updated so that the users themselves never
 have to deal with it. When the second release comes around, we will have
 it begin warning users about the impending requirement update. (Actually,
 depending on how the infrastructure is built, this wouldn't necessarily
 have to coincide with a release, I guess. But it does make sense to tell
 users, "get ready for the next version of WordPress.") Then in the third
 release, the requirement would officially be upped, and new features could
 be introduced in that release that required newer PHP features.

 If we started work on this now, we could try to up the requirement in
 WordPress 5.0, which has a nice ring to it even if WordPress doesn't
 follow semantic versioning.

 However, what percentage to actually use is the question. Given about 60
 million WordPress installs (the number quoted on the homepage), 5% = 3
 million people. However, based on [comment:88 the numbers that @dd32
 shared above], we know that the latest 4 versions of WordPress (4.4-4.7),
 likely represent about half of that right now. These are the people who
 are the most likely to actually update WordPress in the next year or so,
 and they are a full 3/4 of all WordPress users. Of that majority of users
 who mostly haven't abandoned their sites then, that 5% actually becomes
 just 1.5 million people. But wait, the percentage for those newer versions
 isn't 5%. 4.4 was the first version that came in under that, about 4.75%.
 4.7 is at ~2.5%. So we are talking about something like 3.5-4% of these
 users here. Which comes out to closer to just 1 million installs. Yes,
 that is still a lot, but remember that it is actually less than 1.75% of
 all WordPress installs. That is the percentage of WordPress users who are
 likely going to actually want to update in the near future and not be able
 to due to their PHP version, assuming that we dropped PHP 5.2 ''today''.
 But say that it takes us about a year? The total number of installs on PHP
 5.2 will only be about 3.3% then. (Yes, I keep track of all this with
 equations and graphs. :-) That's about 2 million total installs, which
 would come out to something like 500k installs in the latest 4 versions at
 that time, the ones where most users are going to update from. Which will
 be something like 0.8% of WordPress's total userbase.

 500k is a big number. But I don't think it is unreasonable. In fact, I'd
 say that if we set a date now (like WP 5.0), and communicate that to
 hosts, it might end up being significantly lower by the time we feel like
 we need to begin actively trying to educate the affected users about the
 situation.

 As others have mentioned, I think that ideally the ultimate goal would be
 to get to a place where we only support non-EOL PHP versions. That isn't
 going to happen overnight, obviously, and for the next few years, maybe
 even 5, we'll have to just drop EOL versions one by one. But eventually
 though, we should get to the place where there are few enough users using
 EOL versions that we are comfortable switching to a PHP version support
 routine that is based on PHP's schedule. The PHP release schedule seems
 generous enough on its own that at that point it should give users and
 hosts sufficient time to update as each version approaches EOL.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33381#comment:118>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform