Convenção desenvolvedor/Convenção nomes/Versionamento

Convenção desenvolvedor/Convenção nomes/Versionamento 1.1 (Edição mínima)

2013-01-09T20:00:50Z

Linha 1

<<TableOfContents>>

Linha 2

Linha 3

TODO: item c do 9.2

Linha 4

Linha 1

~~New~~

Convenção desenvolvedor/Convenção nomes/Versionamento 1.2 (Edição mínima)

2013-01-09T20:00:51Z

Linha 3

O Demoiselle utiliza uma numeração de versão para os seus artefatos composta por cinco partes segundo a estrutura a seguir:

Linha 3

~~TODO: item c do 9.2~~

Linha 5

}

* maior (major);

* menor (minor);

* correção de bug;

* qualificador;

* número de build.

A maior e menor versão definem o conjunto de funcionalidades do produto de acordo com um planejamento, já o incremento do terceiro dígito da versão é usado sempre que alguma funcionalidade é corrigida sem o acréscimo de funcionalidade.

Podemos ter duas espécies de versões: snapshot ou regulares. Nas versões do tipo snapshot o qualificador assume o valor da data e hora no formato "yyyymmdd.hhmmss" e o número de build é incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

}

As versões snapshot são 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:

}

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) definem a proximidade com a versão final.

Convenção desenvolvedor/Convenção nomes/Versionamento 1.3 (Edição mínima)

2013-01-09T20:00:51Z

Linha 3

<<TableOfContents>>

==Versionamento==

Convenção desenvolvedor/Convenção nomes/Versionamento 1.4 (Edição mínima)

2013-01-09T20:00:51Z

Linha 3

==Versionamento==

== Versionamento ==

Linha 5

O Demoiselle utiliza uma numeração de versão para os seus artefatos composta por cinco partes segundo a estrutura a seguir:

O **Demoiselle** utiliza uma numeração de versão para os seus artefatos composta por cinco partes segundo a estrutura a seguir:

Linha 17

Podemos ter duas espécies de versões: **snapshot** ou **regulares**. Nas versões do tipo snapshot o qualificador assume o valor da data e hora no formato "yyyymmdd.hhmmss" e o número de build é incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

Linha 23

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:

Linha 28

Convenção desenvolvedor/Convenção nomes/Versionamento 1.5 (Edição mínima)

2013-01-09T20:00:51Z

Convenção desenvolvedor/Convenção nomes/Versionamento 1.6 (Edição mínima)

2013-01-09T20:00:51Z

Linha 9

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 verões regulares em 3 níveis:

Linha 9

* maior (major);

Linha 10

* menor (minor);

Linha 11

* correção de bug;

Linha 12

* qualificador;

Linha 13

* número de build.

Linha 11

* micro: para correção de bug e implementação de melhorias;

Linha 12

* menor: implementação de novas funcionalidades;

Linha 13

* maior: implementação de novas funcionalidades com possibilidade de quebra de paradigmas;

Linha 15

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.

Linha 16

Linha 17

~~Podemo~~s ter ~~dua~~s esp~~écie~~s de versões: **snapshot** ou **regulares**. Nas versões ~~do tipo snapshot~~ o qualificador assume o valor da data e hora no formato "yyyymmdd.hhmmss" e o número de build é incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

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 assume o valor da data e hora no formato "yyyymmdd.hhmmss" e o número de build é incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

Convenção desenvolvedor/Convenção nomes/Versionamento 1.7 (Edição mínima)

2013-01-09T20:00:51Z

Linha 15

Linha 16

Linha 17

}

Linha 18

Convenção desenvolvedor/Convenção nomes/Versionamento 1.8 (Edição mínima)

2013-01-09T20:00:52Z

Linha 9

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:

Linha 11

* micro: para correção de bug e implementação de melhorias. Prioritariamente trata Bugs e Improvements. Muda quando há necessidade de manutenção;

Linha 12

* menor: implementação de novas funcionalidades. Prioritariamente trata Improvements e Feature Requests de impacto médio e evolutivo. Muda quando há necessidade de evolução;

Linha 13

* 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;

Linha 14

Linha 15

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.

Linha 16

Linha 17

No Demoiselle, a //depreciação// sinalizada em uma versão deve permanecer na versão <maior> seguinte, só podendo haver //remoção// na próxima. Exemplificando: Se houve uma //depreciação// na versão 1.1.1 do framework, ela deve permanecer durante toda a versão 2.*.*, só podendo ocorrer a //remoção// na versão 3.0.

Linha 18

Linha 19

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

Linha 20

Linha 21

border="1" cellpadding="5" cellspacing="0"| **Característica** | **Maior** | **Menor** | **Micro**

Linha 22

Linha 23

| Escopo | Inovação | Evolução | Manutenção

Linha 24

Linha 25

Linha 26

| span style="padding-left:5%;"|Bug | | X | X

Linha 27

Linha 28

| span style="padding-left:5%;"|Improvement | | X | X

Linha 29

Linha 30

| span style="padding-left:5%;"|Feature Request | X | X |

Linha 31

Linha 32

| Pode haver Depreciação*? | S | S | N

Linha 33

Linha 34

| Pode haver Retirada*? | S | N | N

Linha 35

Linha 36

| Periodicidade Mínima | Semestral | Mensal | Imediata

Linha 37

Linha 38

| Periodicidade Máxima | Anual | Bimestral | Quinzenal

Linha 11

* micro: para correção de bug e implementação de melhorias;

Linha 12

* menor: implementação de novas funcionalidades;

Linha 13

* maior: implementação de novas funcionalidades com possibilidade de quebra de paradigmas;

Convenção desenvolvedor/Convenção nomes/Versionamento 1.9 (Edição mínima)

2013-01-09T20:00:52Z

Linha 11

* micro: para correção de bug e implementação de melhorias. Prioritariamente trata Bugs e Improvements. Muda quando há necessidade de manutenção;

* micro: para correção de bug e implementação de melhorias. Prioritariamente trata Bugs e Improvements. Muda quando há necessidade de **manutenção**;

Linha 12

* menor: implementação de novas funcionalidades. Prioritariamente trata ~~Improvements e~~ Feature Requests de impacto médio e evolutivo. Muda quando há necessidade de evolução;

* menor: implementação de novas funcionalidades. Prioritariamente trata Feature Requests de impacto médio e evolutivo. Muda quando há necessidade de **evolução**;

Linha 13

* 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;

* 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**;

Linha 15

É 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.

Linha 26

Linha 28

| span style="padding-left:5%;"|Bug | | X | X

| span style="padding-left:5%;"|Bug | | | X

Convenção desenvolvedor/Convenção nomes/Versionamento 2.0 (Edição mínima)

2013-01-09T20:00:52Z

Linha 30

| span style="padding-left:5%;"|Improvement | | X | X

Convenção desenvolvedor/Convenção nomes/Versionamento 2.1 (Edição mínima)

2013-01-09T20:00:52Z

Convenção desenvolvedor/Convenção nomes/Versionamento 2.2 (Edição mínima)

2013-01-09T20:00:52Z

Linha 5

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:

Linha 5

~~O **Demoiselle** utiliza uma numeração de versão para os seus artefatos composta por cinco partes segundo a estrutura a seguir:~~

Linha 58

* 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.

Convenção desenvolvedor/Convenção nomes/Versionamento 2.3 (Edição mínima)

2013-01-09T20:00:52Z

Linha 57

Convenção desenvolvedor/Convenção nomes/Versionamento 2.4 (Edição mínima)

2013-01-09T20:00:53Z

Linha 19

No Demoiselle, a //depreciação// sinalizada o que numa versão deve permanecer na versão <menor> seguinte, só podendo haver //remoção// na próxima. 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.

Linha 47

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 ~~assume~~ ~~o v~~a~~lor~~ d~~a data e h~~ora ~~no formato "yyyymmdd.hhmmss"~~ e o número de build é incrementado a cada construção. Segue um exemplo de versão do tipo snapshot de um artefato:

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:

Linha 51

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.

Convenção desenvolvedor/Convenção nomes/Versionamento 2.5 (Edição mínima)

2013-01-09T20:00:53Z

Linha 19

No Demoiselle, a //depreciação// sinalizada o que numa versão deve permanecer na versão <menor> seguinte, só podendo haver //remoção// na pr~~óxi~~ma. 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.

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.

Convenção desenvolvedor/Convenção nomes/Versionamento 2.6 (Edição mínima)

2013-01-09T20:00:53Z

Linha 38

| Periodicidade Mínima | Se~~mestr~~al | Mensal | Imediata

| Periodicidade Mínima | Planejada | Planejada | Imediata

Linha 40

| Periodicidade Máxima | Anual | Bimestral | Quinzenal

| Periodicidade Máxima | Planejada | Semestral | Quinzenal

Convenção desenvolvedor/Convenção nomes/Versionamento 2.7 (Edição mínima)

2013-01-09T20:00:53Z

Linha 40

| Periodicidade Máxima | Planejada | Semestral | ~~Quinz~~enal

| Periodicidade Máxima | Planejada | Semestral | Mensal

Convenção desenvolvedor/Convenção nomes/Versionamento 2.8

2013-04-05T21:26:46Z

Linha 7

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:

}

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:

Linha 8

{{{

}}}

Linha 20

Linha 23

Linha 26

Linha 29

Linha 32

Linha 33

Linha 34

| span style="padding-left:5%;"|Bug ||| X|

Linha 35

| span style="padding-left:5%;"|Improvement ||| X|

Linha 36

| span style="padding-left:5%;"|Feature Request | X | X |

Linha 37

| Pode haver Depreciação*? | S | S | N|

Linha 38

| Pode haver Retirada*? | S | N | N|

Linha 39

Linha 40

Linha 23

border="1" cellpadding="5" cellspacing="0"| **Característica** | **Maior** | **Menor** | **Micro**

Linha 25

~~| Escopo | Inovação | Evolução | Manutenção~~

Linha 27

~~| span style="padding-left:5%;"|Bug | | | X~~

~~| span style="padding-left:5%;"|Improvement | | | X~~

~~| span style="padding-left:5%;"|Feature Request | X | X |~~

~~| Pode haver Depreciação*? | S | S | N~~

~~| Pode haver Retirada*? | S | N | N~~

~~| Periodicidade Mínima | Planejada | Planejada | Imediata~~

~~| Periodicidade Máxima | Planejada | Semestral | Mensal~~

Linha 45

{{{

Linha 46

1.0.0

Linha 47

| | |

Linha 48

| | +- Micro

Linha 49

| +- Menor

Linha 50

+- Maior

Linha 51

}}}

Linha 44

}

Linha 56

{{{

Linha 57

+- Qualificador

Linha 58

| +- Número de Build (opcional)

Linha 59

| |

Linha 60

1.0.0-SNAPSHOT-1

Linha 61

| | |

Linha 62

| | +- Micro

Linha 63

| +- Menor

Linha 64

+- Maior

Linha 65

}}}

Linha 49

}

Linha 67

Linha 71

Linha 74

{{{

Linha 75

+- Qualificador

Linha 76

| +- Número de Build

Linha 77

| |

Linha 78

1.1.0-RC1

Linha 79

| | |

Linha 80

| | +- Micro

Linha 81

| +- Menor

Linha 82

+- Maior

Linha 83

}}}

Linha 55

}

Linha 85

Linha 63

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

Linha 93

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

Convenção desenvolvedor/Convenção nomes/Versionamento 2.9

2013-04-05T21:27:22Z

Linha 7

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:

Linha 13

Linha 30

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

Linha 33

| |Bug | X|

Linha 34

| |Improvement | X|

Linha 35

| |Feature Request | X | X |

Linha 34

~~| span style="padding-left:5%;"|Bug ||| X|~~

Linha 35

~~| span style="padding-left:5%;"|Improvement ||| X|~~

Linha 36

~~| span style="padding-left:5%;"|Feature Request | X | X |~~

Linha 66

+- Maior

}}}

+- Maior

}}}