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 ;-)
