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

Question

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

#1 da (42 voti)
#2 da (2 voti)

32

Stavo spiegando un sistema di costruzione proposto (Gradle / Artifactory / Jenkins / Chef) a uno dei nostri architetti più anziani, e mi ha fatto un commento che I sorta di non sono d'accordo, ma non sono abbastanza esperto da poter davvero pesare.

Questo progetto costruisce una libreria Java (JAR) come un artefatto da riutilizzare da altri team. Per il controllo delle versioni, mi piacerebbe utilizzare l'approccio semantico di:

<major>.<minor>.<patch>

Dove patch indica correzioni di errori / emergenze, minor indica versioni compatibili all'indietro e major indica sia i massimi refactoring dell'API e / o le modifiche non compatibili all'indietro.

Per quanto riguarda la consegna, ecco quello che voglio: uno sviluppatore commette un codice; questo innesca una build in un ambiente QA / TEST. Alcuni test sono eseguiti (alcuni automatizzati, alcuni manuali). Se tutti i test passano, un build di produzione pubblica la JAR sul nostro repository interno. A questo punto, il JAR dovrebbe essere versionato correttamente, e il mio pensiero è stato quello di usare il build.number generato automaticamente e fornito dal nostro strumento CI per fungere da numero di patch.

Pertanto, il controllo delle versioni sarebbe in realtà:

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

Ancora, dove build.number è fornito dallo strumento CI.

L'architetto ha respinto questo, dicendo che l'uso del numero di build dell'elemento della configurazione era un "abuso" del controllo delle versioni semantico.

La mia domanda è: è corretto, e in tal caso, perché? E se no, perché no?

builds versioning continuous-integration continuous-delivery semantic-versioning

posta herpylderp 14.08.2014 - 16:12

fonte

2 risposte

2

Una delle ragioni è che la patch potrebbe richiedere diversi build, quindi se si ha la versione 5.7 e si desidera applicarla su 5.7.1, ma i primi 2 bug non vengono compilati quando vengono inviati al sistema CI, quindi sarai al 5.7.3 prima di rilasciare la tua prima patch!

La risposta è semplicemente usare 4 cifre (come i sistemi Microsoft tendono ad avere). Il 4 è un numero di build e viene utilizzato "solo per informazione". Generalmente le persone inseriscono il numero di versione del repository lì (se usano SVN o TFS o simili), il che è molto bello in quanto è possibile verificare quale commit esatto è stato usato per costruire i binari. Se non si dispone di una cosa del genere, il numero di build CI è un'approssimazione ragionevole (come si spera che il proprio sistema CI possa ricordare i numeri di build e legarlo alla cronologia dei repository, ma non si può fare affidamento sull'elemento della configurazione sistema che li ricorda - non puoi mai cancellare le vecchie versioni).

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 usa la data. Non esiste uno "standard" per utilizzare , ad eccezione del fatto che tutti i numeri devono aumentare.

risposta data 14.08.2014 - 17:07

fonte

Leggi altre domande sui tag builds versioning continuous-integration continuous-delivery semantic-versioning

Che cosa significa Douglas Crockford quando dice che jQuery non scala? [chiuso] Convalida dei parametri del costruttore in C #: best practice

score 42 · Accepted Answer

Il tuo numero di build non verrà reimpostato su 0, quando le versioni minori e maggiori aumenteranno, questo viola le sezioni 7 e 8 delle specifiche :

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

Quindi, i numeri di versione (maggiore, minore, patch) devono essere forniti manualmente, in quanto vengono utilizzati per comunicare agli utenti le modifiche apportate in un'unica posizione senza che debbano guardare il log delle modifiche o qualche altro documento.

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

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.