Quando um commit não deve ser marcado com a versão?

Contexto: Descobri recentemente o Semantic Versioning e estou tentando determinar a melhor forma de usá-lo praticamente para meus próprios projetos.

Como o semver leva em consideração grandes alterações, pequenas alterações e patches para o versionamento, quando um commit não deve ser marcado com uma versão atualizada? Parece-me que todas as mudanças se encaixariam em uma dessas categorias e, portanto, todas as alterações devem ser versionadas, mas quando eu olho para vários projetos populares no GitHub, isso não parece ser o modo como as coisas são feitas (apenas olhando para o fato de que grandes projetos têm dezenas de milhares de confirmações, com apenas centenas de tags).

SemVer preocupações versionamento lançamentos , não compromete . Se o seu modelo de controle de versão exigir que cada commit no master seja uma liberação, sim, todo commit precisará ser marcado de acordo com o grau da mudança.

Geralmente, porém, os projetos desenvolvem um produto praticamente estável no master e marcam os lançamentos que consideram dignos de suporte. Quando o fizerem, serão etiquetados de acordo com o esquema de versão, que não precisa necessariamente ser o SemVer em particular.

Os números de versão são alocados para liberações. Em geral, nem todo commit deve ser um release. Há várias razões para isso.

Em primeiro lugar, enquanto você diz que "testa" cada confirmação, há níveis de teste. A execução de um suíte de testes automatizado em uma máquina é ótima, mas em softwares complexos, provavelmente não vai resolver todos os problemas. Alguns problemas podem ser específicos ao hardware ou à configuração, outros podem ter mais a ver com questões subjetivas humanas do que com requisitos testáveis.

Em segundo lugar, aumentar o número da versão principal deve ser uma ação rara. Basicamente, significa que tudo o que depende do seu software precisa ser verificado manualmente para verificar se depende de algum dos recursos removidos.

Uma conseqüência disso é que você só deve adicionar recursos à sua "API pública" em versões completas (não alfa / beta) se estiver preparado para oferecer suporte a esses recursos na forma atual a longo prazo.

Em terceiro lugar, é útil manter baixo o número de versões em uso generalizado. Mesmo em uma ramificação estável, geralmente é melhor reunir várias correções e fazer uma única liberação do que fazer uma liberação para cada correção.

Parece óbvio, mas: o objetivo dos números de versão é permitir que você determine facilmente qual versão do software alguém está executando.

Se houver alguma chance de alguém ter acesso a uma iteração específica do código e não conseguir determinar facilmente um identificador exclusivo, essa iteração deverá ter um número de versão exclusivo. Eu vejo isso como a 'primeira regra'. Como conseqüência, versões distintas desejarão claramente números de versão distintos.

No entanto, mais entra em jogo:

Uma maneira de ter certeza disso é aumentar os números de versão com cada confirmação, mas isso geralmente não é uma boa ideia. Pode levar várias confirmações / iterações para que uma alteração relativamente pequena funcione, e é confuso para o mundo externo ver a versão 0.0.1 -> 0.0.2 como resultado de um grande número de alterações acumuladas, em seguida, 0.0.2 -> 0.0 .56 porque alguém cometeu espaço em branco corrige um arquivo de cada vez e não alterou nada funcional.

A distância entre "uma versão por versão completa" e "uma versão para cada confirmação" depende realmente de você, dos outros usuários e de quais sistemas você está disposto a usar para preencher as lacunas.

Pessoalmente, estou acostumado a trabalhar em pequenos projetos e fico feliz em usar hashes git até uma versão usada por outras pessoas e uma versão melhorada para cada um deles (não importa o número de pessoas que espero colocar as mãos nele). No entanto, em empresas maiores e em projetos maiores, algo fora dos números das versões semânticas, mas uma fidelidade menor do que cada confirmação, como a numeração de candidatos a lançamento, é usada. Eles têm vantagens, mas aumentam a complexidade.

Toda solicitação pull que é mesclada ao mestre deve ter versão.

Se não deve ser uma nova versão (pelo menos um patch), provavelmente não deve ser mesclada ao master porque o recurso / fix / etc não está completo.

No entanto, dependendo do fluxo de trabalho da sua equipe, você ainda pode acabar com várias confirmações para dominar sem uma versão. Se houver vários commits em uma solicitação pull que não sejam esmagados (eles não deveriam na minha opinião), você ainda poderá acabar com 10 commits e apenas 1 nova versão.