Il tuo pacchetto ha un bug. La sua API in alcuni scenari non segue la documentazione e il comportamento previsto. È stato così perché era v1.0.0. Lo aggiusti per abbinare la documentazione. Dovrebbe essere la prossima versione:
La prima cosa che dovresti fare è assicurarti che i tuoi test siano migliorati, in modo che almeno uno fallisca con il codice corrente e passi quando viene corretto su come avrebbe dovuto funzionare.
Successivamente, se possibile, canvas i tuoi utenti. A volte è facile, ad esempio se si tratta di una licenza a pagamento, potenzialmente si hanno i dettagli di contatto per ogni cliente. Se si tratta di una libreria OOS, potresti non avere idea di chi la usi. Ma se puoi avvisarli, fallo e dai loro feedback se interromperà il loro codice.
Se non riesci a comprimere gli utenti, devi stimare la probabilità che rotti il codice di qualcuno. Quanto è oscuro un bug? Il solo dire "è stato lì fin dalla v1" non dà molto senso a questo. Quanti anni fa è stato rilasciato v1? Quanti 10, 100, 100.000 utenti hai? Se la discrepanza è svantaggiosa per l'utente, allora la probabilità di rompere le cose è inversamente proporzionale a no. di utenti * tempo. Se, però, il codice funziona in un modo che è vantaggioso, allora sarà proporzionale (e direi che dovresti correggere i documenti in quel caso, non il codice).
Se è molto probabile che il codice si rompa in modo significativo, per molti utenti, diventa una release importante. Se è davvero improbabile rompere il codice, falla diventare una patch. Ma anche, prendere in considerazione la probabile reazione a questa correzione. Si sono lamentati centinaia di persone? Se è così, tendi verso un'importante release solo per promuovere il fatto che sia stato corretto. Se nessuno lo ha segnalato, inclinati nuovamente verso una patch.
In conclusione, devi valutare un gruppo di fattori specifici per la tua situazione e sceglierne uno. E ricorda, non importa quale scegli, qualcuno si lamenterà; questa è solo la natura umana:)
Nel caso in cui descrivi, c'è una discrepanza tra l'API pubblica che è documentata e il suo comportamento effettivo. Come presentato, per me il bumping della versione patch sembra la strada da percorrere.
Ma non è necessariamente chiaro.
Ci sono un paio di domande nelle FAQ di SemVer che trattano la questione:
In breve, il contesto è la chiave. Qual è il modo più chiaro per esprimere il tuo punto di vista ai consumatori pubblici di API? Quanto di un impatto sarebbe la soluzione per loro?
Per ribadire, a mio parere dovrebbe bastare il bumping patch. Questo e correttamente la documentazione del bug. L'uso di SemVer non significa che i consumatori pubblici di API possano aggiornare in modo sicuro da una versione all'altra semplicemente guardando il numero di versione; SemVer riguarda la compatibilità e lo sforzo di aggiornamento, non la sicurezza. Quindi dovrebbero controllare la documentazione, inclusi i changelog e i problemi noti (che possono essere rilevati tra il momento in cui la versione è rilasciata e che scelgono di aggiornare) prima di eseguire l'aggiornamento, e verificare che l'aggiornamento non interrompa la loro applicazione prima di impegnarsi a esso.
Ma alla fine, fai ciò che è meno probabile che possa alienare i tuoi utenti API pubblici, che conosci meglio di me.
semver ha solo tre regole. e in realtà si riduce a uno.
Altrimenti, puoi discutere se stai aggiungendo una funzione o meno e usi minori o patch come preferisci.
Se interrompi la prima regola, rompi tutti quelli che usano le catene di dipendenza della tua biblioteca.
Li imponi a specifiche versioni esatte anziché 1.x
Le persone smetteranno di usare il tuo software.
Leggi altre domande sui tag semantic-versioning