Come convertire l'ultimo rc (o altra pre-release) nella versione di produzione usando semere?

5

Il versioning semantico incoraggia l'uso dei suffissi per indicare i pre-release: build alpha, beta o rc. Il loro scopo è ben noto e documentato.

È anche un dato di fatto che una volta creata una build o una versione, il suo nome non dovrebbe cambiare. Tutti i gestori di pacchetti o repository che conosco quindi non supportano questo (NuGet, NPM, Bower).

Non è contraddittorio?

Quando business o QA approva una determinata build di pre-release (probabilmente un rc, ma forse anche qualcosa che etichettato come beta risulta essere pronto per la produzione), non è possibile rimuovere il tag di pre-rilascio. E suppongo che tu non voglia creare una build completamente nuova (senza un tag di pre-release), che potrebbe introdurre un errore (umano) come accidentalmente puntare a un altro commit o revisione. Per evitarlo con certezza, dovrai eseguirlo di nuovo attraverso la tua strada DTA e rieseguire i test di accettazione.

Su una nota più filosofica, questo sembra così contraddittorio che non capisco come questa nozione di prerelease sia persino riuscita a seminare. Sembra che questa nozione di quale fase ti aspetti che il software consegnato sia dovrebbe essere solo metadata , non qualcosa da includere nel numero di versione effettivo.

Sono sconcertato dal fatto che non riesco a trovare praticamente nessuna discussione su questo argomento. Non tutte le aziende che eseguono versioni e test del software eseguono questo problema? Cosa mi manca? O sono solo eccessivamente preoccupato di costruire e ridistribuire una versione finale dell'ultimo rc approvato?

Nota che ho trovato queste due domande che sembrano uguali, ma non offrono risposte chiare:

posta Vincent Sels 23.02.2017 - 09:59
fonte

1 risposta

3

Primo: non è necessario rimuovere la versione preliminare. Che questa revisione molto specifica fosse una pre-release è un fatto storico e non vedo buone ragioni per nasconderlo.

Secondo: basta aggiungere il tag di rilascio alla stessa revisione. Se capisco correttamente SemVer, questo non dovrebbe essere un problema.

Supponi di usare git:

git tag -a v1.2-rc2 9fceb02

Quindi, quando v1.2-rc2 risulta essere pronto per la produzione, fallo

git tag -a v1.2 9fceb02
    
risposta data 23.02.2017 - 10:25
fonte