14 Comments


  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.


  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.


  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.


  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.


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


  6. @Jeff – Also, the popularity of the plugin also comes into play when coming up with a strategy. If it’s a relatively new plugin or doesn’t have thousands of users, I think developers could get by with more releases for minor fixes.


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


  8. @David Decker – lol, it’s a damned if you do, damned if you don’t scenario. There is no one release strategy for all plugin developers to follow.


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


  10. @Keith Davis – Use Batcache. IMHO it’s simpler and better than those giant bloated plugins everyone seems to like using.


  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.


  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?

  13. Ulrich

    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.


  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.

Comments are closed.