Semantic versioning for content websites

Question

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?

Answer 1

Can you do it ?

The semver was designed for software, and more precisely for software APIs, as laid down in its first clause:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

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:

• If versioning is meant to inform the user about the necessity to read/view the content, then you could decide that a major change would be a restructuring that would require to review everything, whereas a minor change would only require to read a set of added/changed sections. A patch level would mean only rewording/clarification/fine tuning.
• If versioning is meant to manage dependencies between contents (e.g. cross-linking of websites, cross-referencing of documents), then you could take the same approach than semver, by looking at the probable impact on other documents (for a document the simple renumbering of chapters could require to review every cross-reference elsewhere; for a website, a full rewrite wouldn't necessarily imply a major impact if you'd preserve all the URLs)
• If it is for marketing purpose, then decide an arbitrary thresholds on the effort that your team has to invest for the new version. Don't worry: marketing is not bound by strict rule, so just change the thresholds as suit the needs or take the next highest major version number of your nearest competitor ;-)

Answer 2

Semantic versioning isn't applicable. A website is generally only available in one version at a time, and if readers need to refer to an old version they will do it by date, e.g. "softwareengineering.stackexchange.com as it appeared on 18 September 2019", so the audience of a website generally has no reason to be interested in a version number.

The OP didn't say what problem(s) they were trying to solve with a version number scheme. If the creators of a website need version numbers I would suggest an automatic numbering scheme based on dates, times, and/or a sequence of integers.