Maybe I’m more observant than I used to be, or maybe there is a trend that’s actually happening, but one thing that I’ve noticed is that more and more WordPress developers are beginning to take interest in semantic versioning.
In short (and straight from the website), semantic versioning works like this:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Easy enough to remember, right?
One of the things that sticks out, however, is that certain parts are meant to be updated and changed when there are “incompatible API changes”, when there are backwards-compatibility changes, and when there re bug fixes (and, in which I include, hot fixes).
This clearly makes sense in the context of a larger application such as, you know, WordPress itself, but Themes?
Let’s be honest: most WordPress Theme Updates don’t necessary fall under these same changes because they don’t have an API. Even more so, it raises the question of what would be considered a backwards-compatible change?
Or do they?
The more I’ve given this some thought, the more I think semantic versioning works just fine for WordPress theme updates, and it’s something that I’d love to see continued to be implemented.
