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 (in all cases, I maintain the right to change this!)

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.

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.