Semantic versioning e suddivisione di una libreria, fornendo una build in bundle

Question

Semantic versioning e suddivisione di una libreria, fornendo una build in bundle

#1 da (4 voti)

3

Ho una libreria JavaScript bella, abbastanza popolare che sta seguendo Versioning semantico .

La libreria corrente ha alcune librerie di dipendenze, che sono disponibili come download separati o come parte di un singolo download in bundle. Vedo la necessità di andare più avanti su questa strada. Voglio estrarre librerie aggiuntive più piccole dall'unica libreria più grande. Ognuna di queste librerie estratte sarebbe di nuovo disponibile come file separati o all'interno di una build in bundle.

Se seguo questo percorso di estrazione delle librerie e fornendo una versione in bundle del codice finale, ciò richiede una modifica completa della versione in versioning semantico? Dovrei sborsare da 1.x a 2.x?

Il mio primo pensiero è no: non cambierò alcuna API pubblica, quindi non devo cambiare il numero di versione principale. Ma poi mi chiedo ... beh, sto ristrutturando un sacco di cose, anche se l'API finale per la versione in bundle sarebbe la stessa.

C'è una risposta chiara da semiver su qualcosa di simile? Devo battere il primo, il secondo o il terzo punto? O qualcos'altro?

versioning semantic-versioning

posta Derick Bailey 14.08.2013 - 16:03

fonte

1 risposta

Leggi altre domande sui tag versioning semantic-versioning

Cose da fare prima di andare in produzione Sto facendo eventi giusto?

score 4 · Accepted Answer

Dovresti incrementare il numero della patch (terzo).

Mentre non risolvi un bug, stai rifattorizzando, cioè modificando la struttura del problema senza cambiarne il comportamento. Non stai inoltre modificando l'API pubblica.

Citazioni pertinenti da Versioning semantico qui sotto

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

-

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.