I’ve spent my entire career (going on 27 years) in web development. Websites are constantly changing, and given the nature of a website (some static assets like images aside), every time you interact with it, you’re interacting with the latest iteration of its software. There’s no downloading and installing websites. If the site admins want to push out new code, they can do it whenever they deem it appropriate. (For example, seconds after I published this post, I noticed a typo in this paragraph, so I went in and edited it.) Large sites like Facebook and Twitter are constantly pushing out new code, many times a day, often A/B testing different versions of the same code with different users.
While I’ve generally worked on (much) smaller-scale projects than Facebook or Twitter, that’s been my approach for over a quarter of a century.
Software development is different, especially in the “olden days” when an app (we called them “programs” back then) was something you had to go to a physical retail store to purchase on physical media like CD-ROMs or floppy disks, bring home, insert into a drive in your computer, and install. Updates, if they ever came, would require repeating that process. Eventually, once almost everyone had their computers connected to the Internet 24/7, it became possible to download and install semi-frequent updates to add bug fixes and new features. And now many of us are accustomed to just letting the apps do this themselves with auto-updates.
WordPress plugins are a weird in-between in this setup. They’re part of a website, but they’re not the website itself. They’re software you download and install/activate, and they have frequent updates, which you can configure to auto-update by themselves. (Hint: As both a plugin developer and a builder of custom websites for clients, I strongly recommend turning on auto-update for WordPress and all plugins, unless there are specific ones you know you’ve had issues with in the past.)
What am I getting at here?
Like I said, the majority of my career has been in building websites, and cranking out those updates whenever it seemed appropriate. I’m still adapting to a different way of operating with a software product, ICS Calendar and ICS Calendar Pro. In the early days of the plugin, its user base was small enough that I could just roll out updates whenever I saw fit, including multiple times a day, if I didn’t catch a bug before it was released.
Now, with a comparatively large and growing user base, it’s becoming important to take a more deliberate approach to updates. I’ve gotten some feedback recently that has reminded me that this frenzy of updates, while it may work for me, can be a bit overwhelming for users.
All of that said, I still recommend turning on auto-updates. Set it and forget it! When WordPress first introduced auto-update, I was as reticent about it as anyone, but I’ve been using it on dozens of WordPress sites for many years now, and only twice has it ever caused an issue. Not updating regularly is much more likely to cause problems. If you let a large number of updates accumulate, and then try to run them all at once, you’re far more likely to have a major version change in one or more plugins, which could introduce instability, and making all of those changes at once also makes it harder to pinpoint which plugin caused the problem.
So, am I going to slow down the updates, or what?
My commentary on the benefits of WordPress auto-update aside, users of ICS Calendar may still have reason to ask this question. So, am I going to slow down the frequency of updates to the plugin? Well, yes and no. Mostly yes. Here’s my new plan:
- Regular updates will only be released at most once per week. At this time I am planning on Fridays as the release date, and the next updates for both ICS Calendar (10.10.0) and ICS Calendar Pro (4.8.0) will be released this Friday (March 31).
- Minor bug fix updates will be (mostly) eliminated. If you’re paying close attention to my version numbering scheme, these are the 4-part version numbers (e.g. 10.9.1.1). Moving forward, these will only be done if a bug is causing “fatal” errors (PHP’s term, not mine), or if they are affecting a large number of users. Other bug fixes will wait until the next regular update release.
- Medium-severity bugs may be released as “hot fixes.” A “hot fix” is when software is updated without incrementing the version number. The benefit of a hot fix is that it doesn’t overwhelm users with incremental updates. The downside is that it creates a situation where people who are ostensibly using the same version of software are actually running different code. That’s a big downside, but hot fixes can be useful if a problem is caught very soon after a release, before very many users have had a chance to download the update.
This new approach should ease the concerns of users who have felt ICS Calendar gets updates too often. It remains to be seen what impact this will have on the level of support requests, as a less frequent release schedule will also likely mean a larger number of changes in each version.
As always, your feedback and suggestions are welcome, either in the WordPress Support Forum or by using the Pro Support Request Form. Thanks!
—Scott