Git, versionamento semântico e como ele se encaixa em (minha) linha do tempo típica de desenvolvimento?

Estou trabalhando em um sistema de perguntas e respostas e prestes a marcar meu aplicativo atual com "1.0.0" para sua primeira versão / tag oficial. Ele está prestes a ser lançado para testes beta para um público limitado em seguida. "1.0.0" está correto nesta fase?

Além disso, sem dúvida, haverá muitos erros encontrados nessa fase. Devo mantê-lo como "1.0.0", mas movendo vigorosamente a tag até seu lançamento. Ou, ao corrigir os erros, eu daria uma nova tag "1.0.1". Depois de mais uma rodada de testes, talvez "1.0.2"

Portanto, ao trabalhar em aprimoramentos (por exemplo, novos recursos, como um novo menu, novo campo de entrada de pesquisa), essas seriam pequenas alterações, como em "1.0.0" para "1.1.0"?

Você mencionou que pretende usar o controle de versão semântico, portanto, vamos analisar a especificação do controle de versão semântico em http://semver.org/ :

Dado um número de versão MAJOR.MINOR.PATCH, aumente o:

1. Versão MAJOR quando você faz alterações incompatíveis da API,
2. Versão MENOR quando você adiciona funcionalidade de uma maneira compatível com versões anteriores e
3. PATCH versão quando você faz correções de erros compatíveis com versões anteriores.

Rótulos adicionais para pré-lançamento e compilação de metadados estão disponíveis como extensões para o formato MAJOR.MINOR.PATCH.

e um pouco mais abaixo:

Uma versão de pré-lançamento pode ser indicada anexando um hífen e uma série de identificadores separados por pontos imediatamente após a versão do patch. Identificadores DEVEM incluir apenas alfanuméricos ASCII e hífen [0-9A-Za-z-]. Identificadores NÃO DEVEM estar vazios. Identificadores numéricos NÃO DEVEM incluir zeros à esquerda. As versões de pré-lançamento têm uma precedência menor que a versão normal associada. Uma versão de pré-lançamento indica que a versão é instável e pode não atender aos requisitos de compatibilidade pretendidos, conforme indicado pela sua versão normal associada. Exemplos: 1.0.0-alfa, 1.0.0-alfa.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Portanto, se você estiver lançando uma versão beta verdadeira de sua versão 1.0, deverá marcá-la 1.0.0-beta(ou similar de acordo com as especificações). Se você estiver indo para ter várias versões beta, como você corrigir bugs, então 1.0.0-beta.1, 1.0.0-beta.2etc.

Ao adicionar recursos compatíveis com versões anteriores, você deve aumentar o número MENOR. Se você fizer muitas alterações internas que causariam alterações em outras partes do seu aplicativo, essa é uma alteração PRINCIPAL. Se você estiver fazendo alterações menos drásticas (por exemplo, você adiciona apenas código e não altera o comportamento do código existente), essa seria uma alteração MENOR. Se você tiver um aplicativo pesado da interface do usuário e alterar completamente essa interface, também diria que também é uma alteração MAIOR (a interface do usuário pode ser considerada a API para os usuários finais).

Quanto a como adicionar indicadores ao seu repositório git, sugiro que você primeiro crie um 1.xramo. Isso permitirá que você siga facilmente tudo na versão 1, permitindo o desenvolvimento contínuo da versão 2 no master. Em seguida, você marca a versão beta com uma marca 1.0.0-beta(ou -beta.1se houver vários betas). Depois de corrigir todos os erros que você precisa corrigir, marque a 1.0.0versão real . Em seguida, marque cada versão conforme necessário.

Você pode dar uma olhada em alguns fluxos de trabalho testados e aprovados para o git, como o git flow e o github flow, para obter idéias de como você deseja configurar seu fluxo de trabalho em andamento.

Além disso, se você quiser um pouco mais de contexto sobre o controle de versão semântico para programas sem uma API, essa resposta será aprofundada.

Sim, atualize o número da versão sempre que sair do seu controle e entrar no de outra pessoa.

o motivo é que você precisa saber com o que eles estavam trabalhando. Quando o teste volta e diz "encontramos um bug na versão 1.0.0", a última coisa que você quer é dizer "qual versão 1.0.0, a que fornecemos na segunda-feira ou a que atualizei na sexta-feira? "

A atualização do terceiro número foi realmente projetada para isso; a diferença funcional entre 1.0.0 e 1.0.999 deve ser limitada; quando você adiciona novos recursos grandes e atualiza o segundo número. No entanto, adicionar um novo campo de entrada de pesquisa não conta realmente como uma mudança grande o suficiente para garantir uma atualização do segundo número, mas o YMMV.

Pessoalmente, costumo usar o segundo número não tanto para atualizações de recursos, mas para marcar uma "versão completa", ou seja, uma que passou por teste e passou. Em seguida, atualizo esse valor e repito o vaivém entre dev e test, incrementando o terceiro número a cada vez até que tudo passe.

Boas respostas já fornecidas, mas eu também encontraria uma maneira de incorporar o git sha1 em seu aplicativo, para que você possa descobrir que foi o git commit 1b5619273127398123 que foi o usado nesta versão em particular. Dessa forma, se o Sr. Smith da BigCo ligar e reclamar que seu aplicativo não está funcionando corretamente, você pode perguntar "Qual é a longa fila de dígitos e letras no segundo wor quando você clicar em Sobre?" E git checkout NNNNNNpara obter exatamente isso versão, siga os mesmos passos que o Sr. Smith fez e (espero) reproduza o problema. Não há nada pior do que tentar encontrar um problema que você não pode reproduzir porque está usando uma versão sutilmente diferente (onde você, por acaso ou de propósito, evita esse problema em particular).

Verifique também se o seu sistema de compilação está incluído na versão - incluindo, de preferência, qual versão do compilador e assim por diante - codifique ou armazene quais ferramentas de compilação você usa ao criar o produto dentro do seu repositório git.