For a while now I’ve been using my own, undocumented versioning system for my WordPress plugins 1. 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’ll admit it doesn’t match my current 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

Where…

  • 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.
  1. 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[]