Blog do LuisComS

Este post tem o intúito de mostrar um padrão de versionamento muito usado por fábricas de software, o Versionamento Semântico(Semantic Versioning).As especificações desse padrão encontram-se nesste site: http://semver.org/(em inglês), porém para os preguiçosos segue a tradução de parte da página.

Semantic Versioning

No mundo do gerenciamento de software, existe um lugar terrível chamado “dependency hell“. Quanto mais o seu sistema cresce e mais pacotes você integrar no seu software, maior a probabilidade de você se encontrar, um dia, neste poço do desespero.

Em sistemas com muitas dependências, liberar novos pacotes de versões pode rapidamente se tornar um pesadelo. Se as especificações de dependência são muito apertadas, você corre perigo de “verion lock” (a incapacidade para atualizar um pacote sem ter que lançar novas versões de cada pacote dependente). Se as dependências são especificadas muito vagamente, você inevitavelmente será mordido por “version promiscuity” (assumindo compatibilidade com versões futuras sem ter certeza). O dependency hell é onde você está quando o verion lock e/ou version promiscuity impe-ode mover o projeto adiante de forma fácil e segura.

Como uma solução para este problema, proponho um simples conjunto de regras e requisitos que ditam como números de versão são atribuídos e incrementados. Para que este sistema funcione, você primeiro precisa declarar uma API pública. Esta pode consistir de documentação ou ser executada pelo próprio código. Independentemente disso, é importante que essa API seja clara e precisa. Depois de identificar a sua API pública, você comunica alterações nela com incrementos específicos para o seu número de versão. Considere uma versão no formato XYZ (Major.Minor.Patch). Correções de bugs que não afetam o aumento da API incrementar patch versão, adições/mudanças da API compatível  com versões anteriores incrementar minor versão, e as mudanças API  incompatíveis com versões anteriores incrementar a major versão.

Eu chamo este sistema “Semantic Versioning”. No âmbito deste regime, números de versão e a forma como muda transmite um significado sobre o código subjacente e que tem sido modificado de uma versão para a próxima.

Especificações Versão Semântica

(Semantic Versioning Specification – SemVer)

1. Software que usa Semantic Versioning DEVE declarar a public API. Essa API pode ser declarada no código ou existir em documentação. Quando for feita, ela deverá ser precisa e compreensiva.
2. Um número de versão normal DEVE ter a forma de X.Y.Z, onde X,Y e Z são inteiros. X é o major version, y é o minor version e Z é o patch version. Cada elemento DEVE aumentar numericamente. Por exemplo: 1.9.0 < 1.10.0 < 1.11.0.
3. Um número de versão especial PODE ser denominado ao adicionar uma string abritrária logo após o patch version. Essa string DEVE conter somente alfanuméricos mais o símbolo menos [0-9A-Za-z-] e DEVE começar com um caracter alpha [A-Za-z]. Versões especiais devem satisfazer e ter menor precedência que a versão normal associada. Precedência DEVE ser determinada pela ordenação lexicográfica ASCII. Exemplo: 1.0.0beta1 < 1.0.0beta2 < 1.0.0
4. Uma vez que foi lançada uma versão, o conteúdo daquela versão NÃO DEVE ser modificada. Qualquer modificação deve ser lançada como uma nova versão.
5. Major version que começe com 0 (0.y.z) é para desenvolvimento inicial. Qualquer coisa pode mudar a qualquer momento. A public API não pode ser considerada estável.
6. A Versão 1.0.0 define a public API. A maneira com que o número de versão aumenta é agora dependente dessa API e em como ela muda.
7. Patch version Z (x.y.Z | x > 0) DEVE ser incrementada se somente bug fixes que são compatíveis com versões anteriores são introduzidos. Um bug fix é definido como uma mudança interna que corrige um comportamento incorreto.
8. Minor Version Y (x.Y.z | x > 0) DEVE ser incrementada se novas funcionalidades que são compatíveis com versões anteriores são introduzidas à public API. Ela PODE ser incrementada se muitas novas funcionalidades ou melhorias forem introduzidas no código privado. Ela PODE incluir patches.
9. Major version X (X.y.z | X > 0) DEVE ser incrementada se qualquer mudança que quebre a compatibilidade com versões anteriores são introduzidas na public API. Ela PODE incluir mudanças minor e de patch.

Especificações Tagging

(Tagging Specification – SemVerTag)

Esta sub-especificação DEVE ser usado se você usar um sistema de controle de versão (Git, Mercurial, SVN, etc) para armazenar seu código. Usando este sistema permite que as ferramentas automatizadas inspecionar seu pacote e determinar SemVer de versões lançadas.

1. Quando libera a marcação em um sistema de controle de versão, a tag para uma versão deve ser “vX.YZ” por exemplo, “v3.1.0”.
2. A primeira revisão que introduz SemVer DEVE estar com a tag “semver”. Isso permite projetos pré-existentes a assumir o cumprimento em qualquer ponto arbitrário e por ferramentas automatizadas para descobrir este fato.

Nesta mesma página tem um FAQ que traz dúvidas comuns pra quem inicia essa prática.

Vale a pena dar uma olhada também nesse link: Padronizando o versionamento do seu software com Semantic Versioning

E nesse: Utilização de Trunk, Branch e Tag no SVN