Versão inicial antes de iniciar um novo desenvolvimento ou ao marcar um lançamento, o que é melhor?

Alguns projetos batem versão antes de iniciar um novo desenvolvimento, enquanto outros projetos batem versão ao marcar uma liberação.

Qual abordagem é melhor?

Se o número da versão não for alterado no início da nova fase, os desenvolvedores podem esquecer de alterá-lo e simplesmente lançar o programa.

Se o número da versão foi alterado antes da liberação da marcação, 2 os números da versão (tag e Makefile / AssemblyInfo.cs) não coincidem.

git describe pode fornecer a v1.2.3.4-15-g1234567 se a revisão atual for posterior à v1.2.3.4, mas você já alterou os arquivos para a v1.2.3.5

A principal razão para o número da versão existe para que, quando um bug for descoberto, você possa depurar usando a versão real do código-fonte em que o erro realmente ocorreu (descubra o verdadeiro motivo do bug).

Não importa qual esquema de versão usado, desde que o usuário da sua produção possa se comunicar com o desenvolvedor informações suficientes para que o desenvolvedor possa atingir esse objetivo.

Outras razões para a versão são para equipes de marketing e ajuda (às vezes legais).
Essas equipes têm suas próprias prioridades para controle de versão.

• Ajuda
  Quer uma maneira fácil de determinar a compatibilidade, os recursos e a potencial estabilidade (consulte o esquema de números ímpares pares do Linux).
• Marketing
  quer um número maior a cada vez (de preferência acima de 2)
• Legal
  Quer garantir que você tenha todos os recursos comprometidos antes de aumentar o número.

Em todos os casos, o esquema usado não é importante. Contanto que você seja consistente (ou tenha facilmente disponível documentação altamente detalhada sobre mudanças de significado).

Ao usar números de versão de quatro segmentos, como os assemblies .NET, prefiro usar uma marca de controle de versão para definir os três primeiros segmentos; o quarto segmento é o número de confirmações desde essa marca.

Por exemplo, uma versão é marcada como "v1.2.3". Se git-describeretornar "v1.2.3-4-g1a2b3c4", quando criado, esse assembly será versionado como 1.2.3.4.

Se uma tag for aplicada posteriormente a essa versão, git-describeretornará "v1.2.4", que representa a versão 1.2.4.0. O próximo commit seria então 1.2.4.1.

Os benefícios que encontro deste sistema são:

• Cada confirmação incrementa automaticamente o número da versão.
• Uma versão pode ser lançada em ".0" simplesmente marcando-a.
• Embora não seja perfeito, este sistema funciona com o DVCS porque conta o número de confirmações desde a tag mais recente.