So recently I’ve been asked a number of times on how WordPress version numbers work, as they feel they are doing a lot of security updates recently – in the past week or so we’ve seen 4.1.1, 4.1.2, 4.1.3, 4.2, 4.2.1 and 4.1.4. All complex software will have bugs, some of them security bugs, so patching them often is needed. However it can feel a little overwhelming to those who aren’t in the WordPress community to log in and see required updates every day. This post hopefully will try and explain what to look out for.
WordPress Numerical Standards
Semantic Versioning splits the number into three areas. So the version number is split into three sections: major.minor.patch. The first number indicates a major release of the source code – this often is open to interpretation, but generally when there has been a large amount of code added or rewritten which could affect the running of the software, this is when this number updates. The minor number indicates when a new feature is added generally, but not a massive change in the codebase, and patch number indicates when things such as a bug is squashed. Currently on WP Email Capture we’re on version 2.11, which says that it’s version number 11 of the 2nd major release. Version 2.0 was when the project split into 2, Free & Premium, so I felt it needed an update :).
WordPress however doesn’t follow that as such. In short, it combines the major & minor into one number and patches accordingly. What this means is that rather than go from 2.9 to 2.10 like WP Email Capture, it goes from 2.9 to 3.0. This had lead to some problems as the WordPress 3.0 release was accidentally quite major (it saw the introduction to Custom Post Types), and – comparatively speaking – people thought that the 3.9 to 4.0 should’ve been a big huge release with features that were groundbreaking. It wasn’t (and shouldn’t be), but when you change numbers like that, people get excited.
As well as the above, you have patch numbers. These are always security fixes – so for example if there is a bug discovered that exposes a security flaw, the software will update from 4.0 to 4.0.1.
The Developmental Cycle
Since WordPress 3.7, WordPress’ developmental cycle has changed dramatically. Basically major updates are released a lot more often (3-4 a year usually) rather than 2-3 a year, this has lead to more features being added, but features themselves being smaller. Bigger features, like the JSON REST API, are first released as plugins to test their functionality and squash bugs. When everything is happy that it’s working and causing no issues, it’s merged into the core version.
So at the time of writing, the last major release was 4.2. This introduced a few new features which you can read about on the FireCask blog.
Major releases, by WordPress standards, often see the introduction of new files. As such, these require manual upgrades to get working. Often this is a case of just clicking a button in the back end of WordPress, but due to significant changes in the codebase, you have to push the button yourself.
Minor releases are a bit different, as these are often patched and fixed quickly. These often change only a few lines of code, and no files are added. As such, since 3.7 these are by default pushed out automatically, with a high success rate. Furthermore, the last 3 major releases are also supported, so as well as 4.1.2 being pushed out updates to 4.0, 3.9 and (I think) 3.8 were pushed out, should they needed it.
What you had recently was whilst 4.1.2 came out and was a critical security release, there was an issue with some sites that used an obscure database encoding method that also used non-latin characters, hence why 4.1.3 got pushed out pretty quickly afterwards.
Update: Since this post was written, 4.1.4 (and 4.2.1) have also come out. That is a security release and should be patched (which if you have automatic updates switched on, you’ll see that it probably already has been done).
Unfortunately, due to the time between the updates, and also the XSS Security Vulnerability in WordPress Plugins that happened around the same time, it can be seen that WordPress as a platform is deemed to be insecure. I don’t think it’s the case, it’s just because of it’s popularity and it’s transparent nature, you hear about these issues more than a closed platform (like Facebook). Thankfully there are some talented people working on the software to keep it going and all but one of the security updates were subject to Responsible Disclosure. Even after the last few weeks, I’m still happy to keep WordPress running on my servers. Just as long as you keep things updated and leave automatic updates on, you should be fine too.