Changes between Version 1 and Version 2 of Projeto/Versionamento

Timestamp:

08/10/09 09:57:47 (15 years ago)

Author:

wmerlotto

Comment:

--

Projeto/Versionamento

@@ -11 +11 @@
 
  * Ao ser criado, terá o número 2.0;
- * Todos os módulos terão o número 2.0.000, para regularizar a numeração atual que está confusa;
+ * Todos os módulos terão o número 2.0.xxx, onde o ".xxx" depende das alterações realizadas enquanto estava no trunk, para regularizar a numeração atual que está confusa;
  * 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 módulo que sofrer alguma correção, no branch, terá a sua versão incrementada (por exemplo 2.0.001). Os demais módulos do branch continuam com as suas respectivas versões;
@@ -17 +17 @@
  * 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;
  * 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;
- * No Trac os tickets de correção do branch deverão ser criados com o campo versão = branche 2.0 e milestone = "" (nenhum).
+ * No Trac os tickets de correção do branch deverão ser criados com o campo ''versão = branche 2.0'' e ''milestone = ""'' (nenhum).
 
 == Política para o trunk ==
 
- * Após criado o branch 2.0, os módulos passam todos para versão 2.1.000 (no trunk). 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 tickes concluídos (?), ou atualização em banco de dados (tables_updade), 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 fica bloqueado para novas funcionalidades. Deverão ser comitadas apenas correções de homologação do release candidate;
- * A cada 7 dias (?) uma nova tag candidate será gerada, por exemplo 2.1.rc2, e assim sucessivamente até que a homologação seja concluída;
+ * 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_updade), 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;
+ * 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.