Modelo de Versionamento para os pacotes do Expresso Livre

No geral

• Usar numeração sequencial crescente;
• Primeiro dígito para versão principal. Sinaliza grandes modificações no funcionamento, na estrutura e também no layout;
• Segundo dígito para versões com novas funcionalidades e melhorias implementadas;
• Terceiro dígito para sinalizar atualizações e correções.

Política para as versões em Branch

A versão do Expresso criada no Branch deverá ter um escopo pré-definido, e ser trabalhado para sua publicação na comunidade. Seu versionamento inicial deverá funcionar da seguinte forma:

• A versão principal do pacote "Expresso X",e terá o formato "X.0";
• A versão de cada módulo deverá conter a versão do pacote, seguido do sufixo ".000". Deverá ser incrementada toda vez que sofrer correções e atualizações em seu código do Branch. Independentement, os demais módulos do Branch continuam com as suas respectivas versões;
• Atualizações no Branch, após publicado, devem ser feitas somente em caso crítico. Atualizações em banco de dados somente se absolutamente necessárias. Estão vetadas melhorias de código;
• O Branch (SVN) não muda de versão quando um módulo sofre correção. O Branch X.0 continua lá com o mesmo número (exemplo /svn/expresso/branches/2.0), pois a função do branch é dar a posição mais atualizada da versão 2.0. Contudo, dentro dele podem existir módulos com versão X.0.001, X.0.002;
• Depois que uma correção for feita no Branch, será gerada uma tag, a partir da posição corrigida do branch, que ficará disponível em /svn/expresso/tags/expresso/X.0.001, por exemplo, correspondendo a primeira correção do branch;
• Ao longo do tempo se outras correções forem feitas no branch, ele será sempre X.0, mas teremos as tags, para cada uma das correções realizadas: X.0.001, X.0.002, etc;
• No Trac os tickets de correção do Branch deverão ser criados com o campo versão = Branch X.0 e milestone = Expresso X.0.Y preenchidos, para que sejam encaminhados nas próximas versões do pacote Expresso.

Política para o trunk

• Após criado o branch 2.0, os módulos (no trunk) passam todos para a próxima versão, por exemplo 2.1.000. Esta é a numeração de versão que vai no arquivo setup.inc.php e respectivo arquivo tables_update (se existir);
• No Trac, os tickets deverão ser criados com versão = Trunk, e milestone = Expresso 2.1;
• Cada módulo incrementa a sua versão de acordo com os critérios: a cada 6 tickets concluídos (?), ou atualização em banco de dados (tables_update), ou atualização crítica;
• Passados 4 meses (ou outro critério), do início da versão em desenvolvimento, será gerada a tag 2.1.rc1, a partir do trunk. Neste ponto o trunk ficará bloqueado (virtualmente, pois os desenvolvedores ainda poderão enviar suas alterações) para novas funcionalidades. Deverão ser comitadas apenas correções de homologação do release candidate. O objetivo é unir todos os desenvolvedores para testar e corrigir a maioria dos bugs, para que o lançamento da nova versão seja mais rápido;
• Para validar a atual release candidate, é interessante seguir o Quality Assurance?;
• A cada 7 dias uma nova release candidate será gerada, por exemplo 2.1.rc2, e assim sucessivamente até que a homologação seja concluída;
• Uma vez homologada, será gerado o branch 2.1. Os módulos serão levados ao branch com os seus números de versão corrente no trunk;
• Inicia-se um novo ciclo no trunk com versão 2.2 para todos os módulos. O trunk estará liberado para novas funcionalidades.

Atualização no Trac

• Campo versão conterá: trunk, sandbox, branch 2.0 (não existirá mais 'tags' como versão pois uma tag não deve ser modificada);
• Campo milestone conterá: Expresso 2.1;
• Não existirão mais milestones para módulos, apenas para versões do Expresso;
• Quando um novo branch for criado, também será criada uma entrada no campo versão, por exemplo: branch 2.1