Como é o processo de versionamento de software?

Está pensando em adotar uma convenção para as versões do software que você produz? Tenha em mente que a composição e o significado dos números das versões é uma escolha particular da empresa ou do programador. Você vai gostar deste artigo se estiver considerando formalizar seu versionamento de software, mas também se estiver simplesmente curioso e querendo se aprofundar um pouco nesse assunto.

O processo de desenvolvimento é mais importante

No fim das contas, quem define mesmo o versionamento de software é o processo de desenvolvimento. Os números das versões vão refletir fatos ocorridos dentro do processo, e vão demonstrar sua utilidade na hora de verificar compatibilidades, controlar alterações e manter o cliente feliz, com seus sistemas funcionando.

Dentro do ciclo de vida de um software, as principais razões que podem criar a necessidade de uma nova versão são:

  • Correções de bugs (a campeã);
  • Inclusão ou extensão de requisitos que já existem;
  • Refatoração completa do software ou mudança de arquitetura;
  • Correções menores e ajustes estéticos (geralmente despriorizadas).

Esse raciocínio parte do pressuposto que você usa uma solução de mercado para controlar suas versões, que contempla pelo menos os seguintes recursos:

  • Rastreamento de alterações desde a versão inicial de um artefato;
  • Percorrer o histórico de alterações, com a possibilidade de voltar a uma versão anterior;
  • Controle de acesso que permita o trabalho em paralelo de grandes equipe;
  • Definição de versões em múltipos escopos, desde pequenas alterações até versões terminadas;
  • Ramificação de versões, permitindo uma linha paralela de desenvolvimento.

Comparando o desenvolvimento de software a uma estrada com ramificações, como podemos sinalizar quanto do caminho foi percorrido, quais as estradas escolhidas, e como voltar atrás no caminho? A resposta está nos números de versão, que refletem as decisões tomadas no caminho.

Veja alguns exemplos que podem ajudar a esclarecer

Vamos começar comentando uma convenção de versionamento de software sugerida pela Microsoft para basear nossa conversação num exemplo bem vivo. Eles dividem o número em quatro partes:

(Maior).(Menor).(Compilação).(Revisão)

( (major.minor[.build[.revision]]) no original em inglês )

Essa convenção sugere que você incremente as partes ‘Maior’ e ‘Menor’ para indicar que a nova versão não terá mais compatibilidade com a versão anterior. Por exemplo, sua versão 4.0.0.0 não deve ser compatível com a versão 3.1.5.5. Você deve incrementar a parte ‘Maior’ toda vez que incluir uma mudança significativa no software que vá impedir o uso da versão anterior.

Um incremento na parte Compilação indica uma provável continuação de compatibilidade. Geralmente indica que foi incluído um pacote de correções (patches) ou um upgrade pequeno. Por exemplo, a versão 3.1.8.0 provavelmente será compatível com a versão 3.1.7.0.

Um novo número de Revisão indica a eliminação de bugs menores e pequenos ajustes mantendo a compatibilidade com a versão anterior; uma versão 3.1.8.13 pode ser uma correção mandatória da versão 3.1.8.12.

Percebe melhor agora? Cada evento significativo de dentro do processo de desenvolvimento está refletido de forma incremental nos campos escolhidos para compor o número da versão: pequenas correções, atualizações relevantes, modificações nas bibliotecas e mudanças completas. Registrar estes eventos a partir de uma convenção seguida pela equipe de desenvolvimento permite que todos falem a mesma língua e organizem melhor seu trabalho em conjunto.

Em resumo, o versionamento de software é parte integrante do processo de desenvolvimento quando adotado de maneira formal, e deve ser tratado com o mesmo cuidado e atenção que se dá aos padrões de projeto e metodologias adotadas pelos desenvolvedores de um mesmo time.

Sobrou alguma dúvida? Registre nos comentários e vamos conversar!

About Pedro Costa