WordPress Plugin Versioning

For a while now I’ve been using my own, undocumented versioning system for my WordPress plugins ((my original releases used a system that wasn’t even documented in my head and mainly consisted of me waving a damp finger in the air to determine wind direction)). It’s actually quite similar to the WordPress versioning which is rare amongst plugins, as many use some complete off-the-wall solutions.

However, yesterday I was considering, as part of matching my plugins to the WordPress ecosystem, moving towards using the same solution. After some consideration, though, I’ve decided against it – the WordPress system is as it is because of how they release their code (“since new versions of WordPress are released so frequently we only have a need for major and minor releases”).

So, for the first time, here is my versioning system.

I use a sequence-based version numbering for my plugins, based on change significance

Here are further details of my specific methods…

I’ll admit that below doesn’t match my past methodology 100%, as I’ve changed it to match arguments I’ve read on Make WordPress and elsewhere, so future plugin releases will follow this.

I hope you find it useful and I’ll update this document over time to add any further information that may be of use.

Method: Sequence based identifier in the format x.y.z i


  • x – a major release. A major change *might* mean it can break backwards compatibility but I strive to not do this, if at all possible. However code “bulk” is equally something I am concerned about so will often provide backwards compatibility for some time before finally phasing it out in a major release. After many minor releases and adhoc patches the code is often in need of a re-write and this will often constitute a major release
  • y – minor enhancements are made and any-outstanding bugs and maintenance that could wait
  • z – urgent bug fixes, security or maintenance changes only

The idea is that a “z point” release (e.g. moving from 1.3 to 1.3.1) will only include any changes that can’t wait for the next “y point” release (in the previous example, if they can’t wait until 1.4 is ready).

Categories of Change

  • Enhancement – a new feature that’s added
  • Bug – a fixed bug
  • Security – a security enhancement
  • Maintenance – a change that has been made as a result of a change in WordPress Core, policy, etc. It doesn’t add new features and isn’t a bug.

Breaking Changes

Although I indicate that a major release *may* break backwards compatibility, this may not be the case, not does it mean that more minor changes may not either.

As I strive to move towards more recent standards, whether in PHP or Gutenberg, even minor changes may affect compatibility. If this occurs, I will highlight this, as best I can, within the accompanying README.

  1. in all cases, I maintain the right to change this[]

Talk to me!

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: