O versionamento semântico estimula o uso de sufixos para indicar pré-lançamentos: versões alfa, beta ou rc. Sua finalidade é bem conhecida e documentada.
Também é um dado que, depois de criar uma versão ou compilação, seu nome não deve mudar. Todos os gerenciadores de pacotes ou repositórios que conheço não suportam isso (NuGet, NPM, Bower).
Isso não é contraditório?
Quando uma empresa ou um QA aprova uma determinada versão de pré-lançamento (provavelmente um rc, mas talvez até algo que você chamou de beta esteja pronto para produção), não é possível remover a tag de pré-lançamento. E eu diria que você não quer fazer uma nova compilação (sem uma tag de pré-lançamento), que pode introduzir um erro (humano) como apontar acidentalmente para outra consolidação ou revisão. Para evitar isso com certeza, você terá que reexecutá-lo pela sua rua do DTA e executar novamente os testes de aceitação.
Em uma nota mais filosófica, isso parece tão contraditório que eu não entendo como essa noção de pré-lançamentos chegou ao ponto. Parece que essa noção de em que estágio você espera que o software entregue esteja deve ser apenas metadados , não algo para incluir no número da versão atual.Estou perplexo por não conseguir encontrar praticamente nenhuma discussão sobre esse assunto. Todas as empresas que testam e testam seu software enfrentam esse problema? o que estou perdendo? Ou estou apenas preocupado com a construção e reimplantação de uma versão final do último rc aprovado?
Note que eu encontrei essas duas perguntas que parecem as mesmas, mas não ofereça respostas claras:
Primeiro: você não precisa remover a versão de pré-lançamento. Que esta revisão muito específica foi um pré-lançamento é um fato histórico e não vejo nenhuma boa razão para esconder isso.
Segundo: basta adicionar a tag de lançamento à mesma revisão. Se eu entendi SemVer corretamente, isso não deve ser um problema.
Suponha que você esteja usando o git:
git tag -a v1.2-rc2 9fceb02
Então, quando v1.2-rc2 estiver pronto para produção, faça
git tag -a v1.2 9fceb02