Desenvolver software com responsabilidade está cada vez mais importante e valorizado. Controle de qualidade de software, seja através de boa escrita de código com devidas revisões, com bons fluxos de trabalho e promoção de alterações, até testes automatizados de aceitação, fazem cada vez mais parte do dia a dia de um desenvolvedor mais maduro e preocupado com o ciclo de vida do produto sendo entregue.

No meio disso tudo, um personagem que pouca atenção recebia do desenvolvedor de produto final, passou a vir para superfície e se tornou evidente dentro todos os controles e automações: o número da versão da entrega.

Seja todo um pacote, ou apenas uma biblioteca – também chamada de DLL Dynamic-Link Library – todos possuem o recurso de informar qual é a versão atual do código. Geralmente sendo um código composto por 4 segmentos numéricos:

1.2.3.4

Este número representa o número da versão do assembly, segundo à Microsoft. A idéia final é que, a cada modificação no código, esse números são incrementados, representando assim a última – e mais atual – versão do seu pacote. Comumente é interpretado dµa seguinte maneira:

major.major-rev.minor.minor-rev
  1. Major. Número principal da versão
  2. Major Revision: Revisão da versão principal
  3. Minor: Número secundário, ou de menor importancia, da versão
  4. Minor Revision: Revisão da versão secundária (documentação)

Ainda nas documentações da Microsoft, é possível achar uma segunda interpretação:

major.minor.build.revision
  1. Major: Número principal da versão
  2. Minor: Versão secundária
  3. Build: Número da compilação
  4. Revision: Número da revisão

Simples de entender certo? Pois é, não é simples. E a consequência disso é que esse controle não era usado, ou era usado de forma impírica. Cada um tinha sua interpretação, ou simplesmente colocavam tudo no automático, controlando apenas a versão Major, que era é mais simples, mas perdia-se todo o controle de incremento da mesma, e como ninguém se importava com os números gerados, não tinha valor algum:

The format of the version string is: major. minor. build. revision.
When specifying a version, you have to at least specify major. If you specify major and minor, you can specify an asterisk (*) for build. This will cause build to be equal to the number of days since January 1, 2000 local time, and for revision to be equal to the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.
If you specify major, minor, and build, you can specify an asterisk for revision. This will cause revision to be equal to the number of seconds since midnight local time, divided by 2.

Então, bastava dizer que a versão era 1.*, e o próprio compilador se encarregara dos incrementos. Mas como eu disse, como ninguém se importava com esses números, não tinha valor algum.

Semver – Semantic Versioning

Pensando em regular e trazer todas as interpretações para um ponto comum, o criador do Gravatar, e co-fundador do GitHub Tom Preston-Werner, criou o semver.org e, para quem quiser, podiam adotar sua interpretação para seu próprio controle de versão. E, por adotado uma interpretação muito simples, de fácil entendimento, passou a ter larga adoção. O Semver faz a seguinte interpretação:

major.minor.patch

Onde:

  • Major: quando fizer mudanças incompatíveis na API;
  • Minor: quando adicionar funcionalidades mantendo compatibilidade;
  • Patch: ou Correção, quando corrigir falhas mantendo compatibilidade

Assim fica muito mais simples. Se for apenas uma correção de bug, ou melhoria de performance, sem adicionar novas funcionalidades, incrementa-se Patch. Se houver adição de pequenas funcionalidades, mas nada realmente impactante como mudança do negócio ou dependências, incrementa-se Minor. Agora, se realmente a mudança irá torna-lo incompatível com com a API atual – breaking changes – então incrementa-se Major.

Rótulos adicionais

Rótulos adicionais para pre-release e build estão disponíveis como extensão, ficando da seguinte maneira:

  • Pré-release: 0.0.1-alpha, 2.0.0-beta, 2.0.0-rc1
  • Build: 1.0.3+12345, onde 12345 é o número da build
  • Ambos: 2.0.1-alpha+12344

O rótulo de pre-release é importante para informar ao consumidor de seu pacote que ele ainda é um trabalho em progresso – work in progress – portanto ainda é uma versão instável e está sob constante modificação.

Existem algumas convenções ou princípios sobre isso. Por exemplo, se seu pacote estiver marcado como um rc – release candidate, ou seja, um candidato a ser um produto final – irá não mais irá sofrer grandes alterações, apenas correções, até que esteja maduro suficiente para ser lançado como uma versão final.

Já deixar explícito o número da build é interessante, talvez, apenas em tempo de build n’release, pois é comum uma mesma versão de Patch ter várias tentativas de release até sua publicação. Acompanhe:

fonte: https://pt.slideshare.net/giovanni.bassi/build-e-release-pipeline-com-docker/7

A cada tentativa de de release de um pacote, o número da versão é o mesmo – apesar de haver várias tentativas de build n’release da versão 2.1.0, o que mudaria seria o número da build, sendo algo do tipo:

  • 2.1.0+15001
  • 2.1.0+15012
  • 2.1.0+15029

Caso Angular

Recentemente, no primeiro semestre de 2017, o mais popular framework the desenvolvimento de SPA deu uma reformulada na ordem das versões de seus produtos – até então Angular 1.6 e Angular 2.

De forma repentina, anunciaram uma série de versões que deixaram seus consumidores bem confusos. Agora tem Agular 1.x, Angula 2, 4, mas e o 3? Uma confusão.

No artigo do Eduardo Pires, AngularJS, Angular 2, 4 e etc – Passando a confusão a limpo ele explica bem detalhadamente o que aconteceu. Resumidamente, o Angular passou a adotar o padrão Semver em suas releases, mas para isso, primeiro teria que trazer seus dois produtos, AnjudarJS e Angular – para o padrão em uma tacada só. Ficou assim:

  • Angular 1.6 passou a ser AngularJS 1.6.5
  • Angular 2.0 passou a ser Angular 4.3.2

Mas por quê Angular 2.0 pulou para 4.x?

Afim de alinhar também todos os pacotes do Angular, a versão final deveria ser um incremento da maior versão Major de todos os pacotes. Nesse caso, era o pacote @angular/router, que estava na versão 3.3.x, esse foi quem empurrou todos para o Major 4.x.

O importante é que, agora os produtos AngularJS e Angular seguem o padrão de versionamento Semver, e sempre que houver um incremento na atualização, facilmente identificaremos que house uma correção, uma adição de features, ou uma nova grande versão.

Considerações

Leve a sério todo seu produto, e não apenas sua superficie – como as interfaces da API, ou com clean code ou segregação. Informar os consumidores de seus produtos de suas mudança em um nível bem superficial e de rápido entendimento irá fazer com que confiem mais em suas entregas e poderão optar por atualizar para novas versões com segurança, ou mesmo por optar por postergar sua atualização para um momento mais oportuno. Crie meios para que exista essa opção de escolha, e boas entregas.

Referências

Semver.org – Página oficial

 


Leave a Reply

Your email address will not be published. Required fields are marked *