| 5 | | * Usar numeração sequencial crescente; |
| 6 | | * Primeiro dígito para versão principal. Sinaliza grandes modificações no funcionamento, na estrutura e também no layout; |
| 7 | | * Segundo dígito para versões com novas funcionalidades e melhorias implementadas; |
| 8 | | * Terceiro dígito para sinalizar atualizações e correções. |
| | 5 | O novo modelo para o processo de versionamento dos pacotes do ExpressoLivre tem como objetivo, suprir a necessidade exigida pelas empresas de gerar pacotes de versões sem periodicidade definida, ou seja, flexibilizar o processo de versionamento do pacote ExpressoLivre conforme o tempo e a demanda de cada empresa que compôe a equipe de desenvolvimento do projeto. Além disso, este modelo contempla o versionamento periódico necessário para disponibilizar pacotes de novas versões à comunidade Expresso Livre. |
| 12 | | 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: |
| 13 | | |
| 14 | | * A versão principal do pacote "Expresso X",e terá o formato "X.0"; |
| 15 | | * 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; |
| 16 | | * 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; |
| 17 | | * 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; |
| 18 | | * 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; |
| 19 | | * 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; |
| 20 | | * 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. |
| | 9 | == Problemática do modelo atual == |
| 24 | | * 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); |
| 25 | | * No Trac, os tickets deverão ser criados com ''versão = Trunk'', e ''milestone = Expresso 2.1''; |
| 26 | | * 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; |
| 27 | | * 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; |
| 28 | | * Para validar a atual ''release candidate'', é interessante seguir o ''[wiki:qa Quality Assurance]''; |
| 29 | | * 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; |
| 30 | | * 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; |
| 31 | | * Inicia-se um novo ciclo no trunk com versão 2.2 para todos os módulos. O trunk estará liberado para novas funcionalidades. |
| | 13 | Dessa forma, a linha principal de desenvolvimento, conhecida por “Trunk”, tornou-se um grande problema para todos que queiram gerar versões a partir do mesmo, conforme sua demanda em um determinado momento, visto que o ramo Trunk do SVN não detém nenhuma estabilidade de funcionamento em seu código armazenado. |
| 35 | | * 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); |
| 36 | | * Campo milestone conterá: Expresso 2.1; |
| 37 | | * Não existirão mais milestones para módulos, apenas para versões do Expresso; |
| 38 | | * Quando um novo branch for criado, também será criada uma entrada no campo versão, por exemplo: branch 2.1 |
| | 17 | Como consequência, para que o projeto não fosse prejudicado em virtude dessa instabilidade no Trunk, decidiu-se por criar branches de versões, para que então se pudesse manter o suporte das versões já lançadas, e também, planejar uma nova versão estável para a comunidade. Infelizmente, essa decisão desencadeou uma série de “efeitos colaterais”, já que muitas empresas e membros da comunidade já tinham implementado novas funcionalidades e correções diretamente no Trunk. Sem alternativa, esses colaboradores acabaram desencorajando seus esforços para manter suas contribuições na versão principal, visto que a mesma já não era confiável. Como resultado, os “forkes” acabaram sendo criados. |
| | 18 | |
| | 19 | Por conta disso, e com grande preocupação como o futuro do projeto, o comitê gestor do ExpressoLivre reuniu-se , em carácter de urgência, e aprovou um plano de unificação dessas diferentes versões, com objetivo de eliminar os “forkes” gerados e principalmente, retomar o desenvolvimento colaborativo do Expresso Livre. O ponto principal dessa unificação foi a centralização de todo o trabalho em um único nó Branch do SVN, estável, já com planejamento, testes e homologação pré-definidos, e versão nomeada como Expresso 2.2. |
| | 20 | |
| | 21 | Neste momento, o trabalho de unificação está muito bem encaminhado. Todas as empresas e demais colaboradores envolvidos seguem o cronograma definido pelo CG, mas a problemática descrita ainda é uma realidade dentro do processo de desenvolvimento do Expresso, e se não for solucionado, de nada irá adiantar todo esse trabalho de unificação. |
| | 22 | |
| | 23 | Portanto, visando resgatar a credibilidade e a estabilidade da linha principal de desenvolvimento, bem como garantir a flexibilidade no versionamento de pacotes estáveis do Expresso a partir do Trunk, será proposto um novo modelo para o processo de versionamento do ExpressoLivre. |
