Dovremmo assegnare i numeri di versione per le versioni interne?

Quello che abbiamo fatto sul mio posto di lavoro è contrassegnare ogni build con il numero di build. I numeri di build iniziano da 1 e aumentano in modo monotono. Quindi ogni build interna creata dal nostro sistema di build ottiene un nuovo numero di build. La versione finisce per essere scritta come x.y.z (build), dove x.y.z è la versione che verrà rilasciata (come 5.2.8, o qualsiasi altra cosa). Anche questo viene scritto nell'eseguibile in modo che possiamo dire quale versione viene eseguita. Conserviamo una copia di ogni build del nostro prodotto, anche se non viene rilasciato ai clienti, e abbiamo modo di associare le build con le revisioni dei commit nel nostro controllo del codice sorgente.

Buon senso

Lo scopo della numerazione delle versioni è identificare diverse versioni, allo scopo di trovare il codice esatto corrispondente a qualsiasi versione.

In linea di principio ti interesserebbe:

• versioni che potrebbero ancora essere utilizzate da qualche parte (il software è stato inviato all'esterno dell'azienda o all'interno dell'azienda in un altro reparto e quindi non più sotto il controllo del team di sviluppo prodotto).
• versioni che funzionano bene, in modo che se alcune modifiche potessero davvero rovinare tutto, potresti comunque tornare all'ultima versione affidabile e spedirla se necessario.

Quindi, se una versione ha superato un test di successo, ci si troverebbe nel secondo caso. Quindi un numero di versione avrebbe senso, evento se si tratta di una versione interna.

Approccio più formale

Se applichi Versioning semantico , i criteri per il controllo delle versioni sono ancora la versione:

3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

Non è detto esplicitamente se è una versione interna o esterna, ma entrambi dovrebbero essere considerati. Perché in linea di principio le versioni di sviluppo non sono versioni esterne:

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Ora lo standard SemVer consente una certa libertà nello schema di numerazione per le versioni preliminari:

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

Permette anche di mantenere un numero di versione condiviso tra diverse build differenti:

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.

Quindi la domanda qui non è tanto ciò che distingue un interno da una versione esterna, ma ciò che distingue una build da una release.

Alla fine, la stessa conclusione di prima: una versione che ha superato con successo un processo di test di successo merita di essere ben identificata. Se non si desidera seguire i numeri di build nel proprio sistema di controllo del codice sorgente, è necessario utilizzare un numero di versione appropriato.