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?
  • This is precisely why you see "marketing versions" and "technical versions" of software. Mac OS Leopard was version 10.5. Mac OS Snow Leopard was 10.6. From a SemVer standpoint it was just a release of new features. I'm sure it was far more than that under the hood. Commented Aug 21, 2018 at 14:37

2 Answers 2


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 ;-)
  • 2
    To expand on this answer, I think it would be interesting to take a step back and think about the qualities you want the versioning scheme to have in that present case. Who is using the version number, and what information are there interested in? If it is only to track major website overhaul and that any other change is considered minor, maybe an MAJOR.MINOR scheme would work. Another interesting way to look at it would be not to consider the human end-users, but tools like robots/scrapers. With that perspective the website does look like an API, and using SemVer could make sense.
    – KevinLH
    Commented Aug 21, 2018 at 8:11
  • @KevinLH Thank you for these very interesting thoughts. While I think that webcrawlers do not really depend on a content and proved to work perfectly without any versioning scheme, I believe that you really hit the nail with your question about the intended purpose. Many documents version schemes are just used to track the history and the authors. If this is the main purpose, a wikipedia like timestamp or a simple sequential numbering scheme would be sufficient. But maybe the OP has more specific needs.
    – Christophe
    Commented Aug 21, 2018 at 12:34
  • What do you mean by "the necessity to read/view the content"?
    – Marvin
    Commented Jul 15, 2019 at 2:23
  • @Marvin the semver was originally meant for informing about the level of change and compatibility of the API, so that developers using it can from the version number deduce what kind of impacts to expect on their own software (from « should work as before » to « everything has to be rechecked »). With the sentence « the necessity to read the content », I tried to transpose this behavior to readers, i.e. the change of version could inform previous users if they do not have to reread the documents, if they should read some revised parts of it, or if they should better reread everything.
    – Christophe
    Commented Jul 15, 2019 at 5:50

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.