Cancel

Jeff Chandler

Supported Legacy Branches For WordPress.org?

Randy HoytThis is a guest blog post written by Randy Hoyt, author of the blog, RandyHoyt.com. He’s also the founder of Web development firm Amesbury Web.

The recent attacks on older versions of WordPress have made security a hot topic in the community. There has been finger-pointing and mud-slinging from many different directions, but there has also been some good discussion about how to move the project forward. I agree with Jeff, David, and others that responsibility ultimately lies with web site owners. While the official WordPress development blog states that the WordPress team is doing everything they can, others have been wondering if more could be done. I would like to get a discussion going here at the tavern about something that I think would help: a supported legacy branch.

What’s A Legacy Branch?

Newer versions of WordPress currently come with security fixes, but also with added functionality, database changes, and redesigned interfaces. Many users are quite happy with the functionality of their existing version of WordPress, but there is currently no way for them to get only the security fixes without also getting all the other changes. According to the existing WordPress release strategy, only the current branch is supported. When a security issue was found in WordPress 2.8.2 this summer, the new version 2.8.3 was released to fix it. Older versions like WordPress 2.6.5 were also vulnerable to this issue, but no fix was released for them because they were no longer supported. Many software companies and projects do choose to support older versions, and I would like to suggest that the WordPress team supported one legacy branch for around 18 months.

How Might It Work?

Looking back through WordPress’s release history, WordPress 2.2.x and 2.6.x could have been supported legacy branches. Imagine a site built on WordPress 2.2 in June 2007. Under my suggested system, the site owner would have applied only security fixes (2.2.x) for the next eighteen months — not needing to upgrade to 2.3 in September 2007, to 2.5 in March 2008, or to 2.6 in July 2008. When WordPress 2.7 was released in December 2008, the 2.2.x legacy branch could have been deprecated and 2.6.x could have then become the supported legacy branch: the site owner would only then need to upgrade to 2.6.5.

Under my suggested system, someone building a new WordPress site would have the choice between installing the most recent branch (e.g., 2.8.4) or the legacy branch (e.g., 2.6.x). The most recent branch would have all the latest features, but it would also need to be upgraded every three or four months. The legacy branch would not have all these new features, but it would need only security fixes applied until it was deprecated: it would not need to be upgraded to the next supported legacy branch (e.g., 3.0.x) until the version after it (e.g., 3.1) was released.

Objections

Many patrons here at the tavern no doubt remember that WordPress used to support the legacy branch 2.0.x. The branch was supported for almost four years, but the WordPress team abandoned it in back in July. I have talked with WordPress team members about this in the past, at WordCamps and over email, and I have received the following objections to such a system:

1. It’s too much work to maintain.

There is no way for me to deny it: it’s definitely more work to support a legacy branch than not to support one. But it is a known quantity of work. How much work does it take to recover from the negative press generated from large attacks? If a supported legacy branch increases the number of users who keep their WordPress installations secure, the project team could spend less time responding to the latest round of “WordPress is Insecure!” blog posts and more time working on the software.

2. There’s no demand for one.

I certainly believe that there was no demand for the 2.0.x legacy branch. WordPress then had a fairly limited set of features compared to WordPress today. Since the web is constantly evolving, I wouldn’t expect there to be a demand for software three or four years old. But WordPress today is a very mature product, and the current version will be more than adequate for many web site owners for another eighteen months. In fact, WordPress 2.6 was a very good product: many users would have preferred to stay on a secure WordPress 2.6.x instead of upgrading so quickly to a completely new interface.

As the WordPress community grows, many users are not as technically savvy or as anxious to get upgraded features every few months as in the earlier days of the project. They simply want their sites to work, and they rightly fear that an upgrade may break custom themes or plugins. A supported legacy branch would not let them completely off the hook — they would still eventually need to upgrade — but it would greatly ease the burden of maintaining a WordPress web site.

I build business web sites for clients in WordPress. If the WordPress team adopted a system like the one I am suggesting, I would build new web sites on the most recent branch. I would then upgrade my clients every few months until they reached what would become a supported legacy branch. After that, I would be able to upgrade them every eighteen months. I think many WordPress users would be thrilled to have something like this upgrade plan available to them: it would be great if it could be available starting with WordPress 3.0.x.

3. It’s too confusing for users.

This is a legitimate concern, but I have no doubt that a system like this could be adequately explained — and I’m more than willing to help the project team in designing this user experience. Here are my initials thoughts about what could be done:

  1. Two buttons would be needed on the “Download” page, with descriptive text beneath them something like the following:

    [Download WordPress 3.2]
    Contains the newest features but requires more frequent upgrades:
    security patches only available until 3.3 release

    [Download WordPress 3.0.x]
    Legacy branch: security patches available until 3.5 release

  2. The upgrade notifications in the administrative interface could be modified for users on a supported legacy branch. They might see something like this:

    [Red] WordPress 3.0.3 fixes a security issue found in this version of WordPress. Update Now

    … or this:

    [Yellow] WordPress 3.1 adds new features to this version of WordPress. Learn More | Update Now

    … or this:

    [Red] This version of WordPress is no longer supported. You must update to WordPress 3.4.2 to remain secure. Update Now

Discuss

This is a tavern, and I have already monopolized the conversation for far too long. I want to hear from the other patrons: What do you think? Would you be interested in a legacy branch for your own sites? For your clients’ sites? How many users do you think would use such legacy branches? Would existing users feel less upgrade fatigue? Would more people be comfortable staying on or switching to WordPress? Could this help WordPress overcome the recent negative press about security?

Category:
Tags: , , , ,
12

12 responses to “Supported Legacy Branches For WordPress.org?”

  2. In my experience I don’t think the coloured update system will ever work.

    A long time ago before WordPress had built in notification or upgrade support there was a similar type of worm going round and lots of people hadn’t upgraded.

    At the time, as a community member, it saddened me and I did something positive to try and help the situation – http://blog.ftwr.co.uk/archives/2005/06/27/wordpress-version-check/

    I created a plugin to provide an update notification and that plugin had a colour coded update message and even pointed you to the codex page about alpha code being not supported if you were brave enough to be running trunk.

    The things I learnt:

    Colour coding and flashing beacons don’t make people upgrade quicker – they just create noise and make you complacent when it isn’t red and flashing.
    People still ignore the update messages – There are people out there still running my plugin in WordPress 1.5.2 installs – now that is what I call ignoring upgrade messages

    Create forum topic from comment

  3. The core devs have said previously that they don’t support the idea of a “Long-Term Support” version. I assume that this is primarily due to the amount of work involved as the newer code evolves.

    But I have also thought that maintaining the “penultimate branch” (previous release branch) should be doable. This would mean that at any given time, there would be work done on three code branches simultaneously: The current release branch (security, bugfixes), the previous release branch (security, the occasional major bugfix), and the development branch (trunk — new features).

    It wouldn’t give an 18 month window for testing/updating sites, but it would at least give a 3-4 month window (based on the current development cycle), which is better than nothing. When a new version came out, you could stay on the previous version while you tested your plugins and themes against the newest stable release, only upgrading your production sites after you verified functionality. If anything was broken, you’d have time to contact plugin authors or contractors to work on fixes against the new core version, while still being comfortable that you would get security updates on your live sites.

    Betas and Release Candidates are great, but the testing window for those is typically pretty short. I can see how it would be impractical for somebody maintaining dozens of client sites to do property testing in the time between the first RC and the official release of a new version.

    I might also suggest that they should add some more committers to the core team, even if they limited some them to just backporting security updates to the previous version branch. Surely they could recruit a couple of trusted people that they could notify when they make security or major-bugfix changes in the main code, and have them backport them to the previous version. There would be plenty of volunteers for such duty (heck, I’d do it).

    Create forum topic from comment

  4. WordPress is a community driven project. If you want a feature, write it. The same goes for this — if someone wants a legacy branch, then they should step up and volunteer to port patches to their older version of WordPress. I think it’s being selfish and asking to much to expect that the already busy core devs maintain multiple versions of WordPress.

    @Dougal Campbell – I don’t see the need for more people with commit access rather than having them just submit patches and poking a committer for them to commit it.

    Create forum topic from comment

  5. @Viper007Bond – Sure, anybody could try backporting patches, filing a ticket, and nudging a committer. In some cases, that process works. A few versions back, I contributed a patch to let us mass-reenable plugins after deactivation, argued my use-case, and got it committed — a couple of versions later. But stuff like that was much faster and easier when I had direct commit access :)

    But I think people want the reassurance of “officially committed support”. They want a black-and-white public statement that there will be “support” for a given version (at least in terms of bug/security fixes), and that a process is in place to ensure that it happens in a reasonable way.

    The reason for suggesting additional committers is to address the “extra workload” that such backporting might theoretically generate. In cases where the current-branch patch applies cleanly to the previous-branch, the extra work is pretty light. But in cases where the code involved changed too much between versions, it seems like having some extra help dedicated to the previous-branch work would be a boon.

    And note that I didn’t ask the core devs to simply do more work — I volunteered to step up and help. My free-time is pretty minimal, but I’m not suggesting anything that I’m not willing to help out with, if possible.

    Create forum topic from comment

  6. This is a good idea, but is something I think would be better suited to a forked product. Someone needs to launch a separate site to maintain the older, crappier, but in theory more stable, version of the software. I don’t see enough benefits in it for the core devs to be spending time on a product that is essentially useless for 99.9% of WordPress users.

    Create forum topic from comment

  7. @Chris – I’m not sure this is true. I think many users realize that upgrading from 2.6.4 to 2.6.5 or from 2.7 to 2.7.1 is a lot less risky than upgrading from 2.7.1 to 2.8. I have seen many users upgrade to 2.6.5 but then stop because they hear the transition to 2.7 was not smooth for all users.

    Create forum topic from comment

  8. @Ryan – I think a supported legacy branch — with upgrades to new versions every eighteen months or so — would be useful to a LOT more than 0.1% of WordPress users. In the earlier days of the project, most of the users actively followed it and were eager for the new features. As the WordPress community grows, many of the new users are less technically savvy and less interested in the software for its own sake — they just want to write about their passions or update information about their businesses.

    Even as a somewhat technically-savvy user, I get tired of upgrading all my web sites every three or four months. Something inevitably breaks in a plugin or in the theme. Spending an hour or two upgrading and repairing each web site adds up to quite a bit of time I spend messing with software instead of writing. I would much prefer to have to do this once every eighteen months and not every four months.

    One other important question related to your 99.9% number: how many more people would become WordPress users if a particular branch were supported for a longer period of time? I have talked with web developers and designers in my local area (Dallas) who have stayed away from WordPress because of its bad reputation for upgrade fatigue.

    Create forum topic from comment

  9. @Viper007Bond – I want this post to generate a discussion about whether or not a legacy supported branch would benefit the WordPress community as a whole. I think it would, but some commenters disagree. I hope that discussion continues, here and elsewhere. I’m a member of the WordPress community, starting a discussion with other community members about what release strategy would benefit the community: I think it’s a bit harsh to call that selfish and asking too much

    WordPress is a community-driven product, and I believe the WordPress project team is open to hearing feature requests and other feedback on the software from that community. I think quite a lot of users are experiencing upgrade fatigue and considering abandoning WordPress: many such users would much rather have a supported legacy branch than (for example) the ability to rotate and crop their images. If the WordPress blog ran a poll asking users if they wanted to upgrade less often, I imagine a majority of users would say yes.

    Create forum topic from comment

  10. My 99.9% number was a measure of how many people are likely to have trouble upgrading if they have their site setup well. Almost all problems with upgrading are caused by sloppy coding of plugins or themes and/or weird server configurations. The number of people experiencing real problems would be extremely low I imagine.

    Create forum topic from comment

  11. @Ryan – I have heard this claim a number of times — that only sloppy plugins and themes will break in an upgrade — but I strongly disagree with it. The simple fact of the matter is that the WordPress development team cannot test every use of the API or other customizations to WordPress. It is up to plugin authors and theme developers and technical users to test that and make fixes; it gets wearisome having to re-test all these things on many live sites every three or four months.

    Here are just a few examples that I don’t think are the result of sloppy coding:

    * WordPress provides $wpdb for executing queries. Sometimes the data needed is not available in supported API call, so the database must be queried directly. Many category-related plugins broke from 2.2 to 2.3. I don’t think plugin authors are sloppy if they use $wpdb to retrieve data that is not available any other way.

    * I wrote some CSS in a theme that styled one of the default widgets. After the upgrade from 2.7 to 2.8 with the overhaul of widgets, the HTML for the widget had changed enough that my CSS no longer styled the widget at all.

    * I wrote a custom plugin that generated multiple shortcodes together, one after the other: [shortcode][shortcode][shortcode]. In WordPress 2.7, this worked fine; after my upgrade to WordPress 2.8, only every other shortcode was processed. Trying to fix it, I added spaces in between the shortcodes … and then everything worked fine. I don’t think this was sloppy on my part; there’s nowhere in any shortcode or plugin documentation that I could find that clearly states that shortcodes have to be separated by a space.

    Every time I upgrade a site, I find issues like these. I don’t think that they can all be blamed on sloppy coding, but — even if they could — I think it would be a mistake simply to dismiss them. These issues keep people from upgrading, regardless of whose to blame for them.

    Create forum topic from comment

  12. @Chris: I think a legacy branch would be intended for users who desire to run stable software — you could infer that such individuals would be *more likely* to upgrade because of that vested interest.

    @Dougal The longer period of time a legacy branch is supported, the better — for both the individual/business running WP, and the team maintaining that branch. A 3-4 month window is too short for companies that use WordPress publicly. Personal bloggers have a much-easier time upgrading their installations than businesses. Time spent trying to always be on the most-current version = time *not* spent doing other things, like running a business.

    @Randy You make excellent points about how feature-rich WordPress has become, especially when describing 2.6.x. By the time of that branch, WP had gained enough useful, regularly-usable features that there wasn’t a huge push to upgrade. This is what kept me on WordPress 2.6.x for the longest time (that, and my breakable custom theme). I don’t know about your idea that more people would adopt WordPress due to the existence of a legacy branch. And if this did increase adoption, it would surely be just businesses who are currently weary of running the latest version of any open-source software.

    I think in general, I support this idea, but I also know I would never use it (my own blog ventures are not highly impacted by upgrades).

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.