Semantic versioning makes the most sense when applied to software that has a public API, which is why that's the very first clause of the definition: semver.org/#spec-item-1
But of course an API doesn't need to be a REST API. Libraries have APIs too; if a function that a user is expected to interface with changes in a way that would break their current code, then that's not backwards compatible.
For applications, the interfaces are mostly UI and not API - but perhaps changing the format of a config file, so configuration needs to be ported, would be a breaking change.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Semantic versioning makes the most sense when applied to software that has a public API, which is why that's the very first clause of the definition: semver.org/#spec-item-1
But of course an API doesn't need to be a REST API. Libraries have APIs too; if a function that a user is expected to interface with changes in a way that would break their current code, then that's not backwards compatible.
For applications, the interfaces are mostly UI and not API - but perhaps changing the format of a config file, so configuration needs to be ported, would be a breaking change.
Given my software is a compiler backed and a cli or config based frontend, I suppose it's only the config based frontend I really need to worry about?