Com base na minha experiência com o gerenciamento complexo de dependências no nível da plataforma corporativa e o versionamento de versões, vim recomendar uma abordagem que eu gostaria de chamar de Versão Semi-Semântica .
Basicamente, ele se baseia no Semantic Versioning 2.0, mas não é tão rigoroso.
Segmentos de versão semi-semântica:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Formato do segmento de versão principal:
MARKETTING.MAJOR.MINOR.PATCH
Cada segmento deve permitir alfanuméricos, mas números puros são recomendados para alterações incrementais lógicas.
Como o SemVer, recomendo os componentes Maior, Menor e Patch para representar camadas de compatibilidade reversa, mas também recomendo a adição de um componente de Marketing . Isso permite que os proprietários de produtos, grupos / épicos de recursos e preocupações comerciais colidam com o componente principal, independentemente das preocupações de compatibilidade técnica.
Diferentemente de outras respostas, não recomendo anexar um número de compilação ao segmento principal. Em vez disso, adicione um segmento pós-lançamento após um '+' (ex: 1.1.0.0 + build.42). O SemVer chama esses metadados de compilação, mas acho que o segmento pós-lançamento é mais claro. Esse segmento é ótimo para declarar os dados do sufixo como não relacionados às informações de compatibilidade no segmento de versão primário. Suas builds de integração contínua podem receber o número da versão anterior anexada com um número de build incremental que é redefinido após cada release principal (ex: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1) Algumas pessoas gostam de colocar o número de revisão svn aqui ou o git commit sha para facilitar a ligação ao repositório de códigos. Outra opção é usar o segmento pós-lançamento para hotfixes e patches, embora valha a pena considerar adicionar um novo componente de lançamento primário para isso. Ele sempre pode ser descartado quando o componente do patch é incrementado, pois as versões são efetivamente alinhadas à esquerda e classificadas.
Além dos segmentos de lançamento e pós-lançamento, as pessoas geralmente desejam usar um segmento de pré-lançamento para indicar pré-lançamentos quase estáveis, como alfas, betas e candidatos a lançamento. A abordagem do SemVer para isso funciona bem, mas eu recomendo separar os componentes numéricos dos classificadores alfanuméricos (por exemplo: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalmente, você deve aumentar o segmento de lançamento ao mesmo tempo em que adiciona o segmento pós-lançamento e, em seguida, solta o segmento de pré-lançamento quando você o supera no segmento de lançamento principal (ex: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Os segmentos de pré-lançamento são adicionados para indicar que a versão de lançamento está chegando, geralmente apenas um conjunto fixo de recursos para testes e compartilhamento mais aprofundados que não mudam minuto a minuto com base em mais confirmações.
A beleza de ter tudo isso definido semanticamente de uma maneira que cubra quase todos os casos de uso é que você pode analisá-los, classificar, comparar e incrementá-los de maneira padrão. Isso é especialmente importante ao usar sistemas de CI para aplicativos complexos com muitos componentes pequenos com versão independente (como microsserviços), cada um com suas próprias dependências gerenciadas.
Se você estiver interessado, escrevi um analisador semi-semântico em ruby . Eu precisava não apenas usar esse padrão, mas ser capaz de gerenciar outros aplicativos que o usavam.