Stanislav Khromov

Update: Please note that the original post predates the announcement that Gutenberg will be in WordPress 5.0 by several months. It is now more important than ever that an LTS for WordPress core is discussed.

Imagine reading the following update notes in a coming version of WordPress:

“We have a number of exciting features for WordPress 5.0. The new Gutenberg editor has replaced TinyMCE and heralded in a new and simpler way to edit any type of content. The Fields API now provides a utilized way for plugins and themes to create fields in the customizer, on any type of content, or in options pages. We also welcome new endpoints in the REST API – which is finally becoming a full-fledged citizen and allow you to build fully JavaScript-based sites.”

Most developers would be very happy to read this changelog. But many also understand that all of this is years into the future. How can we change that?

“The new Gutenberg editor has replaced TinyMCE”

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 is at a crossroads

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

Full-stack impostor syndrome sufferer & Software Engineer at Schibsted Media Group

View Comments

  • Ja. Släpp sargen och kom in i matchen!

  • You are on to something.

  • Please, this.

  • Sounds great to me! Let’s do it.

  • Mark EggeMark Egge

    Author Reply


  • Anh TranAnh Tran

    Author Reply

    Just found your comment on Github issue of Gutenberg. I think this is a good idea. It’s similar to what Canonical do with Ubuntu and it works for them, at least.

    However, I think there are some problems with this approach:

    1. The maintenance effort will be doubled. While most the core contributors are volunteering, it seems to be hard to do that. Probably possible, but need a lot of work when the whole system changes.

    2. Backward compatibility still need to be done properly. This is one of the best thing in WordPress. We saw a similar story in FOSS world when Joomla updates to version 3.0 and all the extensions for 1.0 and 2.0 don’t work. That will be a huge minus for both users and developers. While I support using the latest technology for coding, we should do it without breaking the APIs.

    • Hi Anh,

      Thank you for your thoughtful comment.

      To address your points:

      1.) There is currently a big workload in backporting and packaging 11 releases (3.7 all the way to 4.8) every time there is a security issue. I feel it would be substantially less work to just have 4.9 and the 5.x branch.

      2.) I agree completely with you about backwards compatibility being important. Reading through the discussion over at GitHub* it’s clear that Gutenberg will be added to core and that it will make big changes to the post edit screen. Even if we were to add a space for “legacy PHP metaboxes”, they would be a second-class citizen over the new JS-driven one. So, we will have backwards compatibility, but not an optimal user experience. That’s why I feel having an LTS is a good idea. If you want to stay on the old interface where everything you know and love works indefinitely, you can. I imagine there will constantly be a trickle of people going from 4.9 to 5.0 as sites get shut down, rehauled, and as and new ones get built. So in 3-5 years usage of 4.9 will probably have dropped substantially.


Next Post