Puoi farlo?
Il semere è stato progettato per il software e più precisamente per le API software, come stabilito nella sua prima clausola :
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.
Questo perché l'obiettivo del semere era migliorare la gestione delle dipendenze del software. Questo è il motivo per cui l'intera formulazione riguarda i cambiamenti nell'API pubblica che possono o meno avere un impatto sul codice dipendente.
Quindi in linea di principio non dovresti usarlo per un altro scopo, perché la formulazione non sarebbe pertinente.
Se lo fai
Ciononostante, alle persone piace applicare i principi di base del seminale per software senza API pubblica . Sicuramente perché lo schema è ben noto e molto logico. Il consiglio è quindi di applicare la dicitura alla sola interfaccia pubblica offerta dal software: la sua interfaccia utente.
L'applicazione di questo schema di controllo delle versioni ai contenuti fa un passo in più: non si tratta più di software. Potresti comunque applicare l'analogia "interfaccia utente" per i tuoi contenuti: gli utenti tendono a fare affidamento sull'organizzazione nota del contenuto (capitoli in un libro, struttura della pagina su un sito web).
Quindi, perché non provarci? L'ostacolo principale è che gli utenti non hanno alcuna dipendenza dal contenuto, quindi avrai alcune zone grigie.
Se ti piace applicare il semere ai contenuti, potrebbe essere più facile assegnarlo a un sistema di gestione delle versioni personalizzato, adattato ai contenuti aggiungendo alcune definizioni accurate sulle modifiche principali / secondarie. Questo sarebbe meno ambiguo. E, chissà, se il tuo schema sembra efficace e i tuoi colleghi lo apprezzano, potresti anche considerare di renderlo pubblico.
Modifica: esempi:
I commenti alla mia risposta mostrano che vale la pena di pensare allo scopo previsto del proprio sistema di controllo delle versioni. Quindi ecco alcuni pensieri aggiuntivi:
- Se il controllo delle versioni ha lo scopo di informare l'utente sulla necessità di leggere / visualizzare il contenuto, allora si potrebbe decidere che un cambiamento importante sarebbe una ristrutturazione che richiederebbe di rivedere tutto, mentre un cambiamento minore richiederebbe solo di leggere un set di sezioni aggiunte / modificate. Un livello di patch significherebbe solo la riformulazione / chiarificazione / messa a punto.
- Se il controllo delle versioni ha lo scopo di gestire le dipendenze tra i contenuti (ad es. cross-linking dei siti Web, riferimenti incrociati dei documenti), si potrebbe adottare lo stesso approccio rispetto al semere, osservando l'impatto probabile su altri documenti (per un documento la semplice rinumerazione dei capitoli potrebbe richiedere di rivedere ogni riferimento incrociato altrove; per un sito Web, una riscrittura completa non implicherebbe necessariamente un impatto maggiore se si conservassero tutti gli URL)
- Se è a scopo di marketing, quindi decidere una soglia arbitraria sullo sforzo che il tuo team deve investire per la nuova versione. Non preoccuparti: il marketing non è vincolato da regole rigide, quindi modifica semplicemente le soglie in base alle esigenze o prendi il prossimo numero di versione maggiore del tuo concorrente più vicino ;-)