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: