Perché build.number è un "abuso" di versioning semantico?

Stavo spiegando un sistema di costruzione proposto (Gradle / Artifactory / Jenkins / Chef) a uno dei nostri architetti senior, e mi ha fatto un commento con cui non sono d' accordo, ma non ho abbastanza esperienza per pesare davvero.

Questo progetto crea una libreria Java (JAR) come artefatto per essere riutilizzata da altri team. Per il controllo delle versioni, vorrei utilizzare l'approccio semantico di:

<major>.<minor>.<patch>

Dove patchindica correzioni di bug / emergenze, minorindica versioni compatibili con le versioni precedenti e majorindica un massiccio refactoring dell'API e / o modifiche incompatibili con le versioni precedenti.

Per quanto riguarda la consegna, ecco cosa voglio: uno sviluppatore impegna del codice; questo innesca una build in un ambiente QA / TEST. Vengono eseguiti alcuni test (alcuni automatizzati, altri manuali). Se tutti i test vengono superati, una build di produzione pubblica il JAR nel nostro repository interno. A questo punto il JAR dovrebbe essere aggiornato correttamente e il mio pensiero era quello di utilizzare build.numberquello generato automaticamente e fornito dal nostro strumento CI per agire come numero di patch.

Pertanto, il controllo delle versioni sarebbe effettivamente:

<major>.<minor>.<build.number>

Ancora una volta, dove build.numberviene fornito dallo strumento CI.

L'architetto lo ha respinto, affermando che l'uso del numero di build CI era un "abuso" del versioning semantico.

La mia domanda è: è corretto, e se sì, perché? E se no, perché no?

— herpylderp
fonte

Risposte:

Il numero di build non verrà reimpostato su 0, quando aumentano le versioni minori e principali, ciò viola le sezioni 7 e 8 delle specifiche :

La versione minore Y (xYz | x> 0) DEVE essere incrementata se all'API pubblica viene introdotta una nuova funzionalità compatibile con le versioni precedenti. DEVE essere incrementato se qualsiasi funzionalità dell'API pubblica è contrassegnata come obsoleta. Può essere incrementato se nel codice privato vengono introdotte nuove funzionalità o miglioramenti sostanziali. Può includere modifiche al livello di patch. La versione della patch DEVE essere reimpostata su 0 quando viene incrementata la versione secondaria.

La versione principale X (Xyz | X> 0) DEVE essere incrementata se vengono introdotte modifiche incompatibili all'indietro nell'API pubblica. Può includere modifiche minori e di livello patch. La patch e la versione secondaria DEVONO essere reimpostate su 0 quando viene incrementata la versione principale.

Pertanto, i numeri di versione (maggiore, minore, patch) devono essere forniti manualmente, poiché vengono utilizzati per comunicare agli utenti le modifiche in un punto senza che debbano consultare il log delle modifiche o altri documenti.

Se vuoi includere il tuo numero di build, puoi aggiungerli dopo un +(sezione 10):

I metadati di compilazione POSSONO essere indicati aggiungendo un segno più e una serie di identificatori separati da punti immediatamente dopo la patch o la versione preliminare. Gli identificatori DEVONO comprendere solo caratteri alfanumerici ASCII e trattino [0-9A-Za-z-]. Gli identificatori NON DEVONO essere vuoti. Costruire metadati DOVREBBE essere ignorato quando si determina la precedenza della versione. Pertanto, due versioni che differiscono solo nei metadati di build hanno la stessa precedenza. Esempi: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

— residuum
fonte

Followup rapido @Residuum (e BTW +1 per la risposta): i numeri di versione dovrebbero sempre essere derivati manualmente allora? In caso contrario, quali strumenti potrebbero essere utilizzati al posto di CI / numero di build?

— Herpylderp,

@herpylderp per niente, la 'spec' di Tom Preston-Werner è solo la sua opinione, un sacco di altre aziende hanno standard diversi (generalmente molto simili tra loro). Nella maggior parte di questi, un numero generato automaticamente fa parte della versione. Utilizzare il numero di build CI è una cosa ragionevole da fare.

— gbjbaanb,

È comunque possibile utilizzare lo strumento CI, se lo strumento consente di eseguire l'aritmetica sui numeri di build. Qualunque build venga rilasciata come aggiornamento della versione principale o secondaria, collegare quel numero di build a un'espressione per la stringa di versione che sottrae dal numero di build CI corrente. Voilà, hai appena reimpostato il numero di build su zero per la nuova versione, senza effettivamente reimpostare il numero di build.

— KeithS

Per quanto mi riguarda, utilizzo semplicemente [major]. [Minor]. [Revision]. [SVN-Version] per DLL e [major]. [Minor]. [SVN-Version] per installatori. Il numero di build CI è solo per uso interno, per indicare dove una build non riuscita potrebbe essere stata rieseguita con lo stesso identico codice base dopo una modifica all'ambiente CI (installazione di un certificato chiave, aggiunta di librerie comuni al GAC ecc.).

— KeithS

@gbjbaanb et al .: In ogni discussione sul "versioning semantico" di cui facevo parte, la definizione da semver.org era l'argomento. Cerca nel web "versioning semantico", e almeno nella prima pagina trovi i pro / contro sulla definizione da semver.org . Sei libero di usare i tuoi schemi di versioning, ma non chiamarlo versioning semantico, poiché questo termine è chiaramente definito.

— Residuum,

Uno dei motivi è che la patch potrebbe richiedere più build, quindi se si dispone della versione 5.7 e si desidera patcharla su 5.7.1, ma i primi 2 bugfix non riescono a compilare quando vengono inviati al sistema CI, allora si sarà alla 5.7.3 prima di aver rilasciato la tua prima patch!

La risposta è semplicemente usare 4 cifre (come tendono ad avere i sistemi Microsoft). Il quarto è un numero di build e viene utilizzato "solo a scopo informativo". Generalmente le persone inseriscono il numero di versione del repository (se usano SVN o TFS o simili), il che è davvero bello in quanto puoi verificare quale commit esatto è stato usato per costruire i binari. Se non si dispone di una cosa del genere, il numero di build dell'elemento della configurazione è un'approssimazione ragionevole (poiché si spera che il sistema CI possa ricordare i numeri di build e collegarlo alla cronologia dei repository, ma non si fa affidamento sull'elemento della configurazione sistema ricordandoli - non puoi mai cancellare vecchie build).

Una cosa da notare, lo schema Microsoft per il controllo delle versioni utilizza la terza posizione per i numeri di build. Chrome utilizza solo 1 numero. Ubuntu utilizza la data. Non esiste uno "standard" da utilizzare , tranne per il fatto che tutti i numeri devono aumentare.

— gbjbaanb
fonte

Anche se non esiste uno standard universalmente utilizzato o applicato, la domanda sembra essere specificamente relativa al controllo delle versioni semantico che ha una specifica.

— Doval,

Anche questo è interrotto sul campo, ad esempio il versioning NuGet di Microsoft utilizza semver, in modo discontinuo (usando lo stile pre-release per i numeri di build) e Ruby usa major.minor.teeny.patch . Comunque, dato che il numero di build può far parte del semver, l'architetto stava parlando tosh (anche se, ammettiamolo, dovrebbe essere + build, non in terza posizione).

— gbjbaanb,

Le specifiche SemVer 2.0 sono del 2013 e le specifiche 1.0 sono del 2012 per quanto ne so. È probabile che NuGet e Ruby stessero facendo le proprie cose prima che apparissero le specifiche. Non è che le specifiche di SemVer siano nuove; formalizza solo ciò che le persone hanno già fatto, così possiamo finalmente concordare un modo per farlo invece di una dozzina di variazioni.

— Doval,

"hai la versione 5.7, e vuoi patcharla su 5.7.1, ma i tuoi primi 2 bugfix non riescono a costruire quando vengono inviati al sistema CI, quindi sarai a 5.7.3 prima di aver rilasciato la tua prima patch !" ok, ma allora? Non ricordo nulla in semver dicendo che i numeri non devono saltare.

— Andy,