Um problema que muitas vezes afecta qualquer pessoa que começa a programar seja no código html/css de um website ou num algoritmo para computação de alta performance é a questão de como identificar diferentes versões do código em questão.
Recentemente ao escrever o meu TV Wall andei a pensar cobre como lidar com o numero de versões. Neste caso não há propriamente um grande problema com distribuição dado que o código apenas corre nos meus servidores mas mesmo assim é interessante ter um mecanismo que me permita referenciar as diferentes iterações do código.
Existem varias abordagens para esta questão e eu vou apenas mencionar algumas, dizer porque escolhia uma em detrimento da outra e em que situações acho que cada uma se pode aplicar mas obviamente que estou bastante mais interessado em ver as vossas opiniões e ideias na caixa dos comentários.
1. Usar o numero de revisão do VCS
Uma forma relativamente simples e bastante útil quando se trabalha com um sistema de controlo de versões (algo que, se não fazem, deviam começar a fazer desde ontem) para identificar a versão. É algo relativamente simples e não exige grande esforço mental porém tem os seus contras.
Por exemplo os números possuem pouca ou nenhuma informação para quem não segue o desenvolvimento. Não há qualquer distinção entre versões estáveis ou instáveis por exemplo e por vezes (como é o caso para quem usa git) nem sequer possuem uma forma rápida de comparar a idade de duas versões. São no entanto perfeitas para quem quer lançar muitas versões de desenvolvimento sem lhes atribuir um numero “real” de versão (exemplo: nightly builds).
2. Usar um conjunto incremental de números
Este é um método relativamente simples e fácil de compreender. A versão 2 é maior que a 1, a versão 1.0.0 é maior que a 0.4.0, etc… Serve também para ter versões de desenvolvimento como seria o caso da 0.4.0 que acabei de mencionar mas não permite voltar ao desenvolvimento depois da primeira milestone de forma simples.
Para este problema pode-se resolver usando algo como o esquema alpha/beta mas ao longo dos anos o significado destes nomes tem vindo a perder-se com muito software beta a ser usado como final (ex: gmail) e muito software que devia alpha a ser lançado como beta (ex: firefox 4).
Outra forma de resolver a situação é o sistema usado pela kernel do Linux em que os números com terminação par são estáveis (ex: 2.32) e os com terminação ímpar são instáveis (ex: 2.33).
Existe também outro problema com este sistema a meu ver que é: em pequenos projectos (e por vezes em grandes também) como é que se decide que se atingiu a versão 1? Quando é que se passa à 2? Nem sempre é fácil definir estes critérios e ainda para mais variam de pessoa a pessoa. Milestones obrigatórias para atingir cada versão são quiçá uma boa ideia para colmatar este problema.
3. Usar a data como versão
Este é um sistema que eu pessoalmente gosto bastante e que, para algo que cresce organicamente como um website, faz a meu ver bastante sentido: usar a data actual como versão. Este sistema ficou popular com o Ubuntu que usa a data do mês de lançamento como numero de versão (ex: 10.04).
Existe no entanto um problema ao tentar descrever versões de desenvolvimento e ainda outro quando a data de lançamento se atrasa mas existem soluções para ambos. Para o primeiro pode-se facilmente usar algo como os números de revisão do VCS e para o segundo basta meramente nomear a versão apenas aquando do seu lançamento (claro que isto funciona melhor quando apenas se lança “when it’s done”).
Eu estou pessoalmente a usar este sistema para organizar internamente as versões do meu TV Wall com um esquema do seguinte estilo:
2010.08.12-1 ano.mês.dia-revisão
O ultimo numero serve apenas quando tenho de fazer mais do que uma actualização no mesmo dia porém habitualmente fica em branco.
Este sistema funciona bastante bem para mim e permite-me rapidamente saber quando foi a ultima vez que fiz uma actualização porém tem um pequeno problema ao impedir-me de perceber se a versão é final ou não. Estou a ponderar adicionar uma letra ao fim entre a, b e r (alpha, beta e release respectivamente) para resolver a situação. O que acham?
E vocês? Que esquema de numeração de versões é que usam (se é que usam algum)?