Versionamento #

O Demoiselle utiliza uma numeração de versão para os seus artefatos (framework, componentes, aplicações de exemplo, wizard, process) composta por cinco partes, segundo a estrutura a seguir:

<maior>.<menor>.<micro>-<qualificador><número de build>

Podemos ter dois tipos de versão: regulares ou snapshot. As versões regulares são oficiais e tem suporte na comunidade através do tracker. É possível liberar versões regulares em 3 níveis:

• micro: para correção de bug e implementação de melhorias. Prioritariamente trata Bugs e Improvements. Muda quando há necessidade de manutenção;
• menor: implementação de novas funcionalidades. Prioritariamente trata Feature Requests de impacto médio e evolutivo. Muda quando há necessidade de evolução;
• maior: implementação de novas funcionalidades com possibilidade de quebra de paradigmas. Prioritariamente trata Feature Requests de maior impacto. Muda quando há necessidade de inovação;

É importante salientar a necessidade de contemplar em versões <maior> e <menor> os Bugs e Improvements implementados em versões <micro>, na linha da manutenção, prevenindo a ocorrência de falhas antigas em versões mais recentes.

Nas versões <maior> e <menor> pode haver depreciação, ou seja, a sinalização (através de "marcações" de classes e/ou métodos com o atributo deprecated) de perda de suporte e futura quebra de compatibilidade (o que funcionava na versão anterior não possui garantia de funcionar na nova). A remoção só pode ocorrer em versões <maior>, implicando na exclusão de classes e/ou métodos anteriormente depreciados, quebrando compatibilidade.

No Demoiselle, a depreciação sinalizada o que numa versão deve permanecer na versão <menor> seguinte, só podendo haver remoção na versão <maior>. Exemplificando: Se houve uma depreciação na versão 1.1.1 do framework, ela deve permanecer durante toda a versão 1.., só podendo ocorrer a remoção na versão 2.0.

O quadro a seguir resume as principais características de cada nível.

Os componentes devem ter um planejamento (roadmap) com as mudanças nos níveis maior e menor, definindo assim o conjunto de funcionalidades em versão. Já o incremento do micro não é planejado e ocorrerá durante o ciclos de desenvolvimento de acordo com a prioridade das mudanças. Segue um exemplo de versão regular de um artefato:

1.0.0
| | | 
| | +- Micro
| +- Menor 
+- Maior 

As versões snapshot são liberações intermediárias não oficiais e são usadas para liberar funcionalidade não testadas. Nessas versões o qualificador SNAPSHTOE usado e o número de build pode ser incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

       +- Qualificador 
      |               +- Número de Build (opcional)
      |               | 
1.0.0-SNAPSHOT-1 
| | | 
| | +- Micro
| +- Menor 
+- Maior 

As versões snapshot podem ser geradas automaticamente por um processo de integração contínua sempre que houver alteração no repositório, não são consideradas versões estáveis do produto, assim devem ser utilizadas com cuidado, não sendo indicado seu uso em ambientes de produção.

Em uma versão regular podemos usar como sufixo os termos ALPHA, BETA e RC (release candidate) seguido de um número sequencial que representa o build. Segue um exemplo de versão do tipo snapshot de um artefato:

      +- Qualificador 
      | +- Número de Build 
      | | 
1.1.0-RC1 
| | | 
| | +- Micro
| +- Menor 
+- Maior 

Os qualificadores das versões regulares são opcionais e podem ser usados para definir marcos de liberação de um produto quando o seu desenvolvimento é considerado muito longo, onde a ordem (ALPHA, BETA e RC) define a proximidade com a versão final.

• ALPHA: versões em estágio inicial, ainda em formação, sujeitas a refatorações e com documentação ainda incipiente; Sua disponibilização para a comunidade visa divulgar a idéia e atrair colaboração para amadurecimento da proposta;
• BETA: versões em estágio intermediário com documentação razoável, menos sujeitas a grandes refatorações. Sua disponibilização para a comunidade visa identificar defeitos e oportunidades de melhoria;
• RC: versões em estágio avançado, candidatas a entrar em produção (RC = Release Candidate). Sua disponibilização para a comunidade objetiva identificar ajustes finais antes da estabilização;

Observação: Para o Demoiselle Process, os qualificadores serão apenas uma ou duas letras: a - Alpha, b - Beta, rc - Relase Candidate.