Changes between Version 3 and Version 4 of Projeto/Versionamento


Ignore:
Timestamp:
08/10/09 12:05:45 (15 years ago)
Author:
niltonneto
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Projeto/Versionamento

    v3 v4  
    1717 * 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/2.0.001, por exemplo, correspondendo a primeira correção do branch; 
    1818 * Ao longo do tempo se outras correções forem feitas no branch, ele será sempre 2.0, mas teremos as tags, para cada uma das correções realizadas: 2.0.001, 2.0.002, etc; 
    19  * No Trac os tickets de correção do branch deverão ser criados com o campo ''versão = branche 2.0'' e ''milestone = ""'' (nenhum). 
     19 * No Trac os tickets de correção do branch deverão ser criados com o campo ''versão = Branch 2.0'' e ''milestone = ""'' (nenhum). 
    2020 
    2121== Política para o trunk == 
    2222 
    2323 * 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); 
    24  * No Trac, os tickets deverão ser criados com ''versão = trunk'', e ''milestone = expresso 2.1''; 
    25  * 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_updade), ou atualização crítica; 
     24 * No Trac, os tickets deverão ser criados com ''versão = Trunk'', e ''milestone = Expresso 2.1''; 
     25 * 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; 
    2626 * 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; 
    2727 * Para validar a atual ''release candidate'', é interessante seguir o ''[wiki:qa Quality Assurance]'';