Semantic Versioning (SemVer) è un modello di gestione del versioning finalizzato a rendere esplicito, grazie al modo in cui il numero di versione di una dipendenza evolve, quale sarà l’impatto che il fruitore deve aspettarsi installando una nuova versione della dipendenza.

Non sto qui a raccontarvi i dettagli del funzionamento, semver.org descrive tutto molte bene e in maniera sufficientemente concisa da non poter addurre la lunghezza come scusa.

TL;DR;

Per farla breve se sviluppate un libreria non potete non adottare SemVer, è una questione di buon costume e di rispetto degli altri.

Quello che volete evitare come la peste è di trovarvi in situazioni inutilmente tediose in cui siete obbligati a fare debug di codice altrui per capire perché ad un vostro cliente si è spaccato tutto.

La mossa del client di RavenDB di spostare delle API pubbliche in una minor change è una breaking change bella e buona che se fosse stata documentata correttamente non avrebbe causato i problemi che ha causato.

Se ci pensate diventa ovvio che il problema maggio, oltre a dover rispettare SemVer che è decisamente complesso, è che dovete separare il concetto di release commerciale da quello di release tecnica. Ne parleremo.

Avete mai pensato di usare SemVer? Se l’avete scartato quali sono stati i motivi?