O assunto de hoje é identificadores de versão. Os famosos v1.0, v1.2.5.9, etc.
Todo mudo já viu estes números em software e a maioria acha que entende bem como funcionam e para que servem. Nem todos... Muitos tem uma vaga idéia; alguns tem uma idéia melhor, mas não sabem como incrementar cada campo e poucos realmente sabem qual a real utilidade destes números e quais são os mecanismos lógicos de avançar os números de versão de um software.
Vamos aos detalhes.
Primeiro, por que se tem números de versão? A resposta é simples: Para termos rastreabilidade do software em campo. E o que é isto? É se poder identificar de forma inequívoca qual versão de um programa um usuário estava rodando (por exemplo, para poder auxiliar o usuário ou reportar/corrigir um bug). Sabendo-se o identificador de versão (VID), deve-se ser também capaz de recuperar os arquivos fonte exatos que geraram aquela versão do software (provavelmente usando tags ou baselines de seu sistema de versionamento de fontes). Isto mostra que temos que garantir que nosso software
nunca repetirá um VID, ou seja,
se mudamos qualquer coisa no software, temos de mudar o VID.
Há várias estratégias e formatos de VID possíveis que garantem a rastreabilidade e alguns ainda dão indicações de compatibilidade entre versões do software. Eu vou explicar o mecanismo de 4 dígitos comumente usado, pois ele é simples de entender e amplamente difundido. Neste mecanismo, os VIDs têm a forma M.n.r.b ou M.n.r-b, onde M, n, r e b são números naturais (0, 1, 2, 3...). M é chamado de Major, n é o minor, r é o release (também chamado de patch level e abreviado como p) e b é o build.
Como queremos que qualquer mudança no software cause mudanças no VID, vamos incrementar o build number
cada vez que buildarmos o software (ou seja, gerou os
deliverables -- instaladores, executáveis, etc -- do software, incrementa o build number). Notem que o build number será incrementado SEM TER HAVIDO ALTERAÇÕES NOS FONTES! Alguns vão perguntar: Ué, mas sem alterações nos fontes, então nada mudou e não precisa mudar o VID... Errado! O tempo passou, a máquina em que o build foi realizado envelheceu (pode ter sofrido atualizações de software...), eventualmente até estamos buildando em uma máquina diferente. Ou seja, muita coisa pode ter mudado. Por isso, incrementa-se o build number e assim se tem certeza que não teremos duas cópias com mesmo VID e comportamento diferente. Notem que o processo de incrementar o build number pode e deve ser automatizado. O próprio conjunto de scripts de build ou ferramentas de build deve se encarregar de incrementar o build number, evitando esquecimentos. Detalhe importante: Mesmo que se mude de máquina, o build number tem de ir sempre crescendo, quer dizer, temos de bolar um jeito de que os scripts guardem qual o último build number usado em algum lugar compartilhado e o incrementem. A solução clássica é guardar o buil number (e o resto todo do VID) no repositório de fontes (sistema de versionamento de fontes).
E quando mudamos algo nos fontes? Bom, aí precisamos de um incremento em alguma parte além do build number. Se a alteração foi apenas uma correção de bug ou alteração interna, sem mudança nas funcionalidades do software, se incrementa apenas o release number. Ao incrementar o release number, se volta o build number para zero. Isto faz com que a seqüência de VIDs fique do tipo M.n.0.0, M.n.0.1, M.n.0.2, M.n.1.0, ...
Se houve alteração ou adição de funcionalidades, devemos incrementar o minor ou o major, dependendo do tipo de alteração. O minor é incrementado se podemos garantir que não houve quebra de compatibilidade na nova versão. Isto normalmente ocorre se só houve adições ao software e tudo que se podia fazer antes continua valendo (por exemplo, ler na nova versão os arquivos gerados com a versão anterior, executar as mesmas operações que eram possíveis anteriormente, etc).
Se ocorre quebra de compatibilidade, devemos incrementar o major number. Muitos recomendam também incrementar o major number quando houve muitas alterações no software, mas há que se olhar esta recomendação com certo cuidado, pois é difícil definir o que são "muitas"...
Resumindo a conversa:
- Os números de versão existem para permitir rastreabilidade.
- Há muitos procedimentos (especificações) de como atualizar números de versão que funcionam, garantindo a rastreabilidade (e existem também alguns escritos por aí que não funcionam, portanto, caveat...).
- Um mecanismo lógico possível de ser usado estabelece um identificador de versão de 4 números (major, minor, release e build) incrementados da seguinte forma:
- No mínimo o build number é incrementado sempre que se reconstroi o software.
- No mínimo o release number é incrementado se houve alterações nos fontes.
- No mínimo o minor number é incrementado se houve alterações de funcionalidade no software.
- O major number é incrementado se houve alterações no software com quebra de compatibilidade.
PS.: Se fala em "compatibilidade para trás" (
backward compatibility). Para explicar este conceito, o melhor jeito é usando um exemplo. Imagine que você usa a versão 1.1 de um editor de textos para criar alguns arquivos. Logo a seguir, você instala a versão 1.2 deste editor e cria novos arquivos com ela. Se diz que há
backward compatibility se a versão 1.2 do editor conseguir abrir sem problemas os arquivos da 1.1. O contrário, ou seja, abrir os arquivos da 1.2 usando a 1.1 pode não ser possível, e, por isso, se fala em "para trás". No esquema de versionamento descrito neste artigo, alterações no minor number indicam que há compatibilidade para trás.
PS2: No caso das duas versões do software abrirem arquivos uma da outra, independentemente de qual é mais nova, têm-se compatibilidade total. No esquema de versionamento descrito neste artigo, alterações no release number indicam compatibilidade total.
PS3: O exemplo de abrir arquivos de outras versões é APENAS UM EXEMPLO DIDÁTICO para explicar o conceito de compatibilidade. Na realidade, todas as funcionalidades do software devem ser levadas em conta e cada tipo de software tem coisas diferentes a serem avaliadas. Exemplos: Uma biblioteca com backward compatibility significa que programas linkados com uma versão mais antiga vão funcionar com a mais nova; no caso de servidores, os clientes que sejam feitos para a versão mais antiga do servidor devem continuar funcionando com a versão mais nova; e por aí vai.
Abraços e até o próximo artigo.
LGM
