DEV Community

Matheus Poda
Matheus Poda

Posted on

1

Git & Github: Você sabe o que é SemVer?

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:

Gato quando vê mil dependências

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.

Imagem descritiva do versionamento semântico


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:

Até a próxima!

Image of Datadog

Create and maintain end-to-end frontend tests

Learn best practices on creating frontend tests, testing on-premise apps, integrating tests into your CI/CD pipeline, and using Datadog’s testing tunnel.

Download The Guide

Top comments (0)

Postmark Image

Speedy emails, satisfied customers

Are delayed transactional emails costing you user satisfaction? Postmark delivers your emails almost instantly, keeping your customers happy and connected.

Sign up