How applicable is it to adapt SemVer for content-centric websites (ie/ not web apps)?
Most of the SemVer 2.0.0 specifications able to translate into such type of websites however it becomes vagues when defining following:
- What considers are 'backward incompatible'?
- Modification of existing navigation?
- Change linkages within content of 1 or more pages?
- Rename a page?
- Does 'complete theme rework' considers as a MAJOR version (for it's a refresh of visual design)? or should it be a MINOR version (for it, and assume, results in no feature modifications)?
- Does additon or major modification of a visual element considered as MINOR version?
Best Answer
Can you do it ?
The semver was designed for software, and more precisely for software APIs, as laid down in its first clause:
This is because the semver goal was to improve the management of software dependencies. This is why the whole wording is about changes in the public API that may or may not have an impact on dependent code.
So you should in principle not use it for another purpose, because the wording would not be relevant.
If you do
Nevertheless, people like to apply semver's underlying principles for software without public API. Certainly because the scheme is well known and very logical. The advice is then to apply the wording to the only public interface offered by the software: its user interface.
Applying this versioning scheme to content goes one step further: it's no longer about software at all. You could however still apply the "user interface" analogy for your content: users tend to rely on the known organisation of the content (chapters in a book, page structure on a website).
So why not give it a try? The main obstacle is that users don't have any hard dependency about content, so you'll have some grey zones.
If you like to apply semver to content, it could be easier to fork it to create your own versioning scheme, tailored to content by adding some accurate definitions about major/minor change. This would be less ambiguous. And, who knows, if your scheme appears effective and your team colleagues appreciate it, you may even consider to make it public.
Edit: Examples:
The comments to my answer show that it is worth to think about the intended purpose of your content versioning scheme. So here some additional thoughts: