O mal do versionamento

Você que é desenvolvedor, ou já fez algum projeto, já cansou de adicionar dependências ao seu projeto. De acordo que o projeto vai crescendo inúmeras bibliotecas/serviços vão sendo adicionados e você vai torcer com todas as forças que eles utilizem o padrão de versionamento semântico.

Você vai ficar assim se não tiver um padrão no versionamento das dependências de seu projeto:

Além disso, você a partir de agora, também irá começar a usar na construção de qualquer projeto, API e bibliotecas, pois é uma metodologia incrível que vai salvar você de inúmeros problemas e também ajudará sua API pública, caso vá ter uma, a se tornar ainda mais segura e controlada.

O que é esse padrão SemVar?

SemVar vem de Semantic Versioning, criado pelo Tom Preston-Werner, co-fundador do Github, a metodologia transforma a versão de um projeto em algo compreensível para quem está utilizando e também para quem está desenvolvendo.

Vamos a um exemplo:

Imagine uma API pública com a versão 4.7.6, ela foi construída já aplicando o versionamento semântico, significando que sua versão principal é 1, o 3 significa que foi feito adição de novas funcionalidades que não impactam quem já utiliza ela e o 4 são de ajustes e correções.

O SemVar trata as versões da seguinte forma:

MAJOR.MINOR.PATCH

• MAJOR: Só é alterada quando foi feito uma mudança que tornou a versão anterior incompatível, ou seja, o básico de configuração e funcionamento anterior foi atualizado a ponto de precisar incrementar a MAJOR;
• MINOR: Incrementada quando é feito uma modificação, ou adição de uma funcionalidade, que não tornou a aplicação incompatível;
• PATCH: Alterada quando é corrigido algo na aplicação, seja refatoração, correção de bug, mantendo a compatibilidade.

Especificações básicas

Vou estar abordando alguma das especificações da utilização do SemVer, para mais informações, consulte a documentação oficial.

1. O formato deve ser X.Y.Z, inteiros e nunca negativos, não se deve colocar um 0 antes de um número, por exemplo, 01, 02 e etc;

2. Deve ser aumentado numericamente 1.9.0 -> 1.10.0 -> 1.11.0;

3. Ao iniciar o desenvolvimento, você deve colocar como MAJOR, o valor '0', esse valor significa que é instável e pode sofrer alterações que impactem a compatibilidade a qualquer momento;

4. Quando a aplicação se tornar pública para uso, a versão MAJOR irá para '1', se tornando 1.0.0;

5. Você pode ter tags em suas versões, como beta, alpha, release e etc (1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.).

Dúvidas frequentes

Algumas dúvidas que acho relevante saber:

Quando devo lançar a versão 1.0.0?

Se seu software está sendo usado em produção, ele já deve ser provavelmente 1.0.0. Se você possui uma API estável a qual usuários passaram a depender, deve ser 1.0.0. Se você está se preocupando bastante com compatibilidade com versões anteriores, já deve ser 1.0.0.

O que eu faço se, acidentalmente, liberar uma mudança incompatível com versões anteriores como uma versão menor (minor version)?

Assim que você perceber que quebrou a especificação de versionamento semântico, conserte o problema e lance uma nova versão menor, que corrige o problema e restaura a compatibilidade. Mesmo sob esta circunstância, é inaceitável modificar versões lançadas. Se for apropriado, documente a versão ofensiva e informe seus usuários do problema de forma que eles fiquem cientes da versão em questão.

O SemVer tem um limite de tamanho para string de versão?

Não, mas use o bom senso. Uma string de versão com 255 caracteres, por exemplo, provavelmente é um exagero. Porém, sistemas específicos podem definir seus próprios limites para o tamanho da string.

Conclusão

A ideia desse tópico foi apresentar esse padrão, que é muito conhecido e usado, para que você se atente e veja se já utiliza no seu dia a dia!

Quero deixar uma pergunta para vocês responderem, para até mesmo treinar o conteúdo:

No seu dia a dia você já utiliza esse padrão? Pense e escreva um pouco sobre projetos que você atua e como é usado, ou deveria ser usado?

Obrigado pelo seu tempo.
Compartilhem com seus colegas de estudo/trabalho.
Me acompanhem em minhas redes sociais:

• GitHub
• LinkedIn
• Twitter
• YouTube

Até a próxima!