WordPress needs another long term support version

An ode to WordPress versioning

WordPress 3.7 introduced automatic updates, and while many hardcore developers quickly wanted to find ways to disable them to not disrupt finely-tuned deployment systems, there is no doubt that it was a net win in terms of usability and security for the vast majority of people running a WordPress site.

When 3.8 was released, we saw patches to the 3.7 branch to fix vulnerabilities found in 3.8. This is great, as backporting security updates ensures ample time for users to upgrade. Initially, the word from the core team was that this backporting would take place for the current and previous minor version (for example, 3.8 and 3.7). Everything older than that would be deemed unsafe. In practice, backporting has continued for all security patches released since 3.7 came out, which means that as of  writing this post, the latest 3.7 branch is at version 3.7.18 – having a whopping 18 security patches.

Backporting security updates gets more difficult as versions diverge

I was able to ask the core panel at WordCamp London 2015 about this (31:25 in this video), and the answer was that the official policy on backporting one release back was still in effect, but that the core team  would continue to provide backports “as long as it was possible”, yet reserving the right to drop them at any time. At the time, WordPress 3.7 was at 3.7.4, which shows how badly this approach scales. WordPress has had a real stagnation in new features lately, and I strongly believe the constant consideration for old versions is a major contribution in holding it back.

Having this practice is bad for many other reasons:

• Backporting can rarely be performed automatically, and difficulties in merging patches grow with the difference in versions
• Backporting isn’t perfect. Subtleties between versions might make security patches ineffective or add bugs.
• The amount of releases that needs to be packages keeps growing (which is a problem because the process is in part manual)
• While publicly appearing responsible, it also promotes a sloppy, “not my problem” mindset from site owners.

How do we fix this?

WordPress versioning has the potential to be at an amazing crossroads. We can give users who are not keen to update stability and safety. We can give users who live and breathe WordPress the new features that otherwise so often stagnate and end up as nothing.

A suggestion for moving forwards

• Make WordPress 4.9 the last version in the 4.x branch, and make 4.9 a long term support release.
• Make 5.0 a jam-packed release. Introduce breaking changes as needed.
• Release an update to all branches older than 4.9 with a dashboard notification informing users that support for this version will cease within a certain time span (90 days)
• After 90 days, do one of the following:
  • Accept that older sites will keep running outdated WordPress versions. Face backlash.
  • Force update sites to 4.9. Face backlash (but likely a much smaller one)
  • Force update sites to 4.9, but introduce a compatibility shim that preseves all public API:s that were deprecated since 3.7. This would be the most time-intensive approach, but also the one with minimal backlash.
• Make the 5.x branch a fluid version. All sites update to the latest 5.x branch automatically (so 5.1 would update to 5.2, etc).
• Backport security updates to 4.9.

With this plan, we have successfully solved all pain points.

• Backporting is limited to a single long term support version, instead of 10+ and growing
• Number of packaged releases is reduced to two, instead of 10+ and growing
• We have an opportunity to introduce breaking changes with version 5.0.

Feelings of Déjà vu

You might not even have known it (I certainly didn’t), but WordPress had an LTS – version 2.0. This was in 2008, almost ten years ago, and the web was different then. WordPress was in the Debian stable repo. There were no auto-updates. It was a different world. It’s time to give this approach another try.

Do you think this is a good way forward?

Leave a comment below and make your voice heard.

Image credits: #1 #2 #3