Quale è il vantaggio di adottare Semantic Versioning?

Abbiamo fatto una brevissima e del tutto non esaustiva introduzione a SemVer, ma la domanda è comunque valida.

Il cliente ha sempre ragione

Detto a cui siamo più o meno tutti, dalla nascita, assuefatti e che man mano cresciamo ci rendiamo conto di quanto sia deleterio.
Proverbi a parte, SemVer è solo ed esclusivamente un “favore” che state facendo al vostro cliente. A noi fornitori complica solo la vita ;-)

Perché si

I vantaggi per l’utilizzatore finale di una libreria sono notevoli perché garantire che tra la release 1.5.1 e la release 1.6.0 non ci sono breaking change rende l’adozione di nuove versioni un processo più semplice.

Il mondo Javascript è forse quello dove il problema è più sentito. Il vostro scopo è liberarvi dall’angoscia che l’aggiornamento delle dipendenze porta con se, tipicamente la domanda ricorrente è: chissà cosa si spacca a sto giro.

Perché inevitabilmente qualcosa si spaccherà e sapete già che sarà un’epopea capire cosa e soprattutto capire come metterlo a posto.

Se chi produce la libreria in questione segue SemVer questo diventa un problema minore:

Nel caso specifico Alessandro si riferisce ad un problema leggermente diverso legato alla gestione delle dipendenze, lo affronteremo.

Perché no

Detto perché ha molto senso rispettare SemVer, cerchiamo di capire dove stanno le magagne. Semplicemente una ed una sola magagna: rispettare SemVer è molto difficile.

Vi lascio con qualche esempio di subdola breaking change in C#:

Tralasciamo poi tutte le breaking change nel comportamento.

Cercheremo prossimamente di capire cosa, da produttori di una libreria, possiamo fare per semplificarci la vita, e quindi rendere migliore quella del nostro cliente.