Cancel

Jeff Chandler

Encouraging WordPress Plugin Developers To Create A Sensible Release Strategy

UpdateScheduleIt’s a phrase that’s all too common in open source software development, “iterate quickly, release often“. The idea that any time a bug is fixed or an improvement is made that those fixes should be pushed out immediately to the end-user. The process is wonderful for companies operating under the Software As A Service umbrella but not so much for WordPress plugin developers. Coen Jacobs, a core developer for WooCommerce shared his thoughts on the matter in a recent blog post.

Coen explains that WordPress is now a large CMS and it’s time for plugin developers to help out by creating a sensible release strategy.

It’s the responsibility of the plugin developers to make sure their releases are as stable as they can be. There is no difference there between a plugin that adds social sharing buttons, or a full featured eCommerce plugin.

WordPress is no longer a small CMS, it’s being used in large, professional websites. Plugin developers have a great share in the success of the CMS in general. It’s now time to take it to the next level and make sure that we release updates responsibly and with our end users in mind.

It’s an annoying process to update a plugin three times a week. I’m all for developers taking a more sensible approach to how they release updates. Security fixes should always be released as soon as possible. However, if it’s just a minor fix such as a typo within the plugin’s readme file, there is no need to burden users with an update message.

Category:
Tags: , , ,
14

14 responses to “Encouraging WordPress Plugin Developers To Create A Sensible Release Strategy”

  1. I don’t entirely agree with this. There is a balance needed.

    Just because you have fixed a bug does not mean you should push out an update.

    Just because you have fixed a bug within a day of a previous release also does NOT mean you should NOT push out an update.

    It really depends on the kind of bug that been fixed or the improvement that has been made. If it’s a crucial fix, please, please, please push it immediately. If user’s are annoyed by too many updates, let them be. It’s better to make crucial fixes asap than to try to not avoid users by pushing too many updates.

    Create forum topic from comment

  2. Hi Jeffro
    “It’s the responsibility of the plugin developers to make sure their releases are as stable as they can be.”

    How blatantly obvious is that, but two of my favourite free plugins have just gone the “premium plus lite version” route and the lite versions are causing havoc.

    Won’t mention the plugins, but one is a backup plugin and one a caching plugin.

    Create forum topic from comment

  3. @Pippin Williamson – Yes, after thinking about this topic for awhile, it becomes obvious that there are a few variables that come into play on whether an update gets pushed out or not, regardless if there was an update 24 hours prior.

    I assume every time I upgrade a plugin that it contains bug fixes but I don’t like the idea of updating a plugin three times a week. I’m with you and I mentioned it in the article, any security fix or major issue fixed should be available to users as soon as possible. That’s common sense!

    @Keith Davis – Well, that’s a slippery slope. Were those plugins working fine before they moved to a premium version? It’s a shame when that happens because established users automatically think they are being screwed into buying the plugin instead of using the free version that used to work.

    Create forum topic from comment

  4. “It’s a shame when that happens because established users automatically think they are being screwed into buying the plugin instead of using the free version that used to work.”

    Nail on the head Jeffro and it makes you rather bitter if you’re using it on lots of client sites.

    In fact with one of the plugins functionality has been taken out of the lite version!

    That’s me on the lookout for a new caching plugin, one that’s easy to set up.

    Create forum topic from comment

  5. It is a slippery slope. I’ve been caught in the 3 releases in a week stage with one of my plugins. The first was a user bug, the second and third were poor planning/fixes on my part.

    The one thing I learned – test often and thoroughly and don’t RUSH a fix, even if it’s for a deadly issue, without decent testing. (Yes, decent testing is vague. You know what that should mean to your work.)

    Create forum topic from comment

  7. I am a plugin developer myself and also manage a lot of installs for clients that have to be up to date.

    I can relate to all the above points for one reason or another. However, there’s also quite some contradiction in the statements – here and elsewhere:

    @Jeffro:

    It’s an annoying process to update a plugin three times a week.

    That’s not always “annoying” as there can be security fixes or “stupid dev errors” that causes trouble for the users — both reasons justify prompt updates.

    On the other side, there are also A LOT of users complaining if a plugin gets no update in about 3 weeks, or 3 months or so… There are also blogs – just like this one here – that constantly “warn” users to update all stuff, and also warn users to not use/download plugins that were not updated recently. That is confusing to say the least…

    “Iterate quickly and release often” is an open source motto from the Linux world – it should emphasize this whole open source software culture and how all is going in general – also compared to the proprietary software world.

    My real life practice is that:
    I “collect” all updates on most installs I manage and make update sessions every week or every other week. That works pretty well for me and for every special difference those installs have.

    For me as plugin developer I am not quite sure which route I should follow – based on the discussion. My general conviction hasn’t changed: push out a “real” update (as compared to tiny fix releases…) as soon as possible. And “possible” here means WITH testing but WITHOUT rushing it. Rushing is always a source for new errors…

    Thanks, Dave from Germany :)

    Create forum topic from comment

  9. @Jeffro – Yeah, I fully agree with that! If we differentiate between smaller and bigger plugins (but where to draw the line?), I would say bigger plugins would need some “team” rather sooner than later and especially some release cycle strategy. I am also considering some of that for my plugins – that are still small – but I guess it will help to not get behind with the faster and faster WordPress release cycles. That is sometimes really a burden if you have full pressure of client work, family and all the common stuff :).

    In the current WordPress.org there are often small updates for plugins, with only the readme.txt changed and/or a few translations added. For the translation scenario the “language pack” feature of WordPress 3.7 will become really handy in future when it’s activated for plugins on WordPress.org — where the translations then will pushed separately and not the whole plugin has to pushed. Nacin said on WordCamp Europe that this might happen within the next 12 months or so. That might save a bit of “update load” or “update anger” for some of us :-)))

    Create forum topic from comment

  11. A lot of releases = more downloads = rise through the ranks of popular plugins.

    No wonder developers like to release and iterate quickly, because the behaviour is rewarded, even if it’s a pain for users. So until that behaviour is no longer rewarded the practice of frequent releases will continue.

    Create forum topic from comment

  12. For updates that are not “life-threatening” I usually just push out that one file without committing a whole new version of the plugin.

    That way the people that have downloaded it before my push, won’t know any better and the people that download the plugin after the push will have the “feature” without even knowing it.

    Mostly I update my plugins once every 3 months minimum and now with the development cycle of 2 months for a new WP version that will become every 2 months minimum. You need to at least show that your plugin is compatible with the new WP version right?

    Create forum topic from comment

  13. I have a plugin on the repository. I think it is important to separate bug fix and feature releases. That is why I like semantic versioning. Bug fixes should be released as soon as they have been tested. Regular release cycles are good. In the regular release cycles you only release the features you have developed and tested in that time. The rest half baked stuff gets moved to the next cycle. This makes it easier for users to test the updates and developers to fix any issues.

    Create forum topic from comment

  14. I develop a social network plugin that turns a WordPress site into a social network (www.wpsymposium.com).

    Your thoughts mirror the evolvement of the plugin release strategy. To start with “fix quick, release often” was considered a plus, but feedback was that in theory it was good, but in reality it was a pain for site admins.

    To summarise our experience to where we are now we have a plan/develop/test/fix/release plan with nightly builds and release candidates available pre-release for those who want more involvement.

    A calmer more managed release cycle has been welcomed over the last 12 months, particularly for those admins with large or corporate sites.

    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.