Skip to end of metadata
Go to start of metadata

Introdução

@@@ PREFIXO NA VERSÃO @@@

Política para dígitos (MAJOR, MINOR, PATCH) do versionamento

Como discutido e decidido na thread  http://listas.tecgraf.puc-rio.br/pipermail/javautils-dev/2015-June/001804.html, será adotado o modelo de Semantic Versioning (http://semver.org/).

 

PATCH: Apenas pequenas correções e melhorias, mas que mantém 100% de compatibilidade com a versão antiga, isto é, não causará nenhuma falha de compilação ao atualizar para um novo patch.

MINOR: Adição de novos componentes e refatoração de componentes já existentes. Não haveria, nesse caso, exclusão de nenhuma funcionalidade, apenas adição e alterações que, uma vez feitas, o usuário continua obtendo o mesmo resultado anterior. Também é mantida 100% da compatibilidade com a versão antiga.

MAJOR: Uma nova versão completa. Não haveria nenhuma obrigatoriedade de compatibilidade com a versão anterior, por mais que possa haver componentes iguais nas duas. Componentes podem ter sido removidos, outros podem ter sido totalmente reformulados e possivelmente coisas, componentes novos. Componentes podem ser repensados, tendo novas ideias e abordagens, não necessariamente mantendo o mesmo resultado anterior.

Observação: Como o JavaUtils possui muitos pequenos componentes desconexos entre si, e ele está em constantes atualizações para atender as demandas dos projetos, é possível que isso propicie muitos avanços da versão MAJOR. Uma sugestão para minimizar esse problema é, sempre que possível, em vez de alterar a API ou o contrato de algum componente, marque a API/contrato antigos como deprecated e inclua a versão nova como nova feature, permitindo assim que o avanço ocorra na versão MINOR em vez da MAJOR. Isso também ajuda a informar os projetos das alterações que devem surgir na próxima versão MAJOR, o que pode ajudar na análise de impacto da atualização para uma nova versão MAJOR.

Relação Snapshot e Trunk

É interessante observar que o código trunk de um módulo corresponde a uma futura versão (ainda não lançada) do mesmo. Com o processo mais formal do maven, é importante observar a correspondência de versões 'unreleased' (JIRA) com 'snapshots' (POM). Essa correspondência trouxe, para o projeto JavaUtils, a adoção de um sufixo "-SNAPSHOT" nos nomes das versões unreleased do Jira. Esta nomenclatura facilita a gerência das issues e release notes.

Tipicamente, só existe uma única versão unreleased de módulo JavaUtils no Jira, o que facilita o gerenciamento do projeto e o entendimento deste conceito. 

A figura abaixo é bastante ilustrativa. Ela ilustra o trunk do javautils-gui com seu arquivo pom.xml (no terminal) e a tela de administração de versões do Jira. Observe:

  • As versões no Jira com prefixos de módulo;
  • As versões released sem o sufixo "-SNAPSHOT";
  • As versões unreleased com  o sufixo "-SNAPSHOT";
  • A "gramática" de formação de nomes de versões;

 

Esta nomenclatura não impede que existam várias versões Jira com nomes sufixados por "-SNAPSHOT". Quando isso ocorrer, vai significar apenas um cronograma mais preciso de quais temas (issues) devem entrar em cada versão futura; o que não ocorre normalmente neste projeto. Se essa situação aparecer, o POM (arquivo pom.xml) corrente do trunk deve indicar a menor versão unreleased (-SNAPSHOT) do Jira; que significa a versão futura mais imediata.

 

 

  • No labels
Write a comment…