12 Comments


  1. I think one key thing you’ve overlooked here is that the folks who don’t bother upgrading to the current version of WP will also be less likely to upgrade a branch of WP. It’s a moot point.


  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


  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).


  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.


  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.


  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.


  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.


  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.


  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.


  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.


  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.


  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).

Comments are closed.