Supponiamo che abbia una libreria, che fondamentalmente funzioni come facciata per alcuni servizi cloud (ad esempio l'API JavaScript che avvolge le chiamate di rete verso un qualche servizio RESTfull). E una volta che quel servizio introduce un cambiamento incompatibile con le versioni precedenti.
Ci sono due possibili scenari a cui riesco a pensare, e non sono sicuro di come gestire entrambi nel modo migliore.
-
In un caso più semplice, la mia libreria in qualche modo riesce a gestire quell'incompatibilità con le versioni precedenti (e ora diventa un adattatore). Quindi spedisco una versione patch perché l'API della mia libreria non è cambiata, e la versione precedente ora ha un qualche tipo di comportamento bacato (si basa su API esterne che non esistono più). Il problema qui è che tutti i programmi già costruiti, così come quelli che usano qualche tipo di blocco delle dipendenze, sono ora danneggiati e devono aggiornare le loro dipendenze. Bene, posso dire che non è un mio problema, ma mi dà fastidio un po '.
-
In un caso più complesso e più reale, la mia libreria non può astrarre quell'incompatibilità all'indietro e ne trapela, quindi devo modificare anche un'API pubblica della mia libreria. Quindi, spedisco una versione principale. Il problema è che rompe l'intero punto di SemVer, in cui l'utente suppone di avere la libertà di decidere dove vogliono avere un aggiornamento importante o no, perché una versione principale precedente dovrebbe funzionare insieme a quella nuova. Ma non è e non può essere patchato.
Capisco che l'approccio SemVer non dovrebbe gestire tali casi. Ma non ho idea di cosa dovrebbe. C'è qualche approccio a questi casi là fuori?