O documento descreve o processo de gerenciamento de versões de um software durante seu desenvolvimento, incluindo linhas de desenvolvimento principais e secundárias, marcos no processo ("congelamento" de versões) e como o GeneXus administra essas funcionalidades.

3. Durante o processo de construção da aplicação, é necessário marcar marcos no desenvolvimento
da mesma, entendendo como marcos o “congelamento” do desenvolvimento num determinado
momento especial no processo. Isto pode acontecer por exemplo para liberar uma versão na
produção, congelar uma versão entregue a um cliente, a necessidade de congelar um determinado
estado especial da aplicação, etc.
Além disso também vamos querer ter diferentes linhas de desenvolvimento da aplicação, algo muito
comum por exemplo quando se quer fazer variações do projeto para um cliente ou quando se requer
que dois grupos de trabalho o façam em paralelo e necessitamos poder realizar uma administração
de todos estes elementos.
O que necessitamos basicamente é administrar o “ciclo de vida” da aplicação durante o
desenvolvimento. Várias destas funcionalidades entram no que no mundo do software se conhece
como SCM (Software Configuración Management)

4. Começa o desenvolvimento seguindo uma linha principal de desenvolvimento (linha do meio – Trunk),
lugar onde são agregadas as funcionalidades requeridas e são utilizados protótipos para prová-las .
Em determinados momentos deste ciclo surge a necessidade de estabelecer um checkpoint no
processo, seja pela liberação de uma versão, a entrega de uma versão a um cliente, a necessidade
de congelar um determinado estado de uma aplicação, etc. Então o que fazemos é congelar o
produto nesse momento criando por exemplo a versão 1.0 que a entregamos a um cliente e continua
o processo de desenvolvimento principal.
Em determinado momento surge a necessidade de realizar correções sobre a versão entregue ao
cliente (1.0) sendo necessário abrir uma nova linha de desenvolvimento para incluir estas correções
sobre o que era a versão 1.0 sem afetar a linha de desenvolvimento principal que continuou
crescendo desde o momento que foi congelada a versão 1.0.
Então se cria o que se conhece como Developmen Version ou branch, que é simplesmente uma nova
linha de desenvolvimento paralela a principal.
Depois durante o transcurso do projeto voltam a aparecer requerimentos deste tipo, seja pela
determinação de checkpoints como a necessidade de abrir novas linhas de desenvolvimento, então
por exemplo criamos a versão 1.1, ou a 1.0.1 que vem a ser um congelamento da linha de
desenvolvimento aberta a partir da versão 1.0 e assim sucessivamente até ter por exemplo a situação
estabelecida no diagrama.
Estas situações formam parte da operação normal no desenvolvimento de uma aplicação e é
necessário administrar este processo de forma fácil.
.
Para isso se introduz o conceito de Gerência de Versões. As versões são classificadas em:
•Development Versions, representam as linhas de desenvolvimento da aplicação as quais são
independentes entre si, existe uma linha principal e várias paralelas, a principal vem a ser o que se
conhece como Trunk e as demais seriam o que em SCM se conhece como Branches
•Frozen Versions (também conhecidas como Labels em SCM), representam as congeladas criados
em determinados momentos do processo sobre as DV para determinar certos checkpoints (liberação
de versão, entrega ao cliente, congelar estado, etc.)

6. As development version são as linhas de desenvolvimento da aplicação, isto é o lugar onde
efetivamente criamos e modificamos a aplicação.
No ciclo de vida de uma aplicação participa uma linha de desenvolvimento principal, isto é, onde
começa o processo de desenvolvimento da aplicação e na qual normalmente se vai estar fazendo as
modificações requeridas no avanço do projeto. Em SCM esta linha de desenvolvimento é conhecida
com o nome de Trunk.
Além desta linha principal poderão existir uma ou várias linhas de desenvolvimento secundárias,
totalmente independentes da linha principal e independentes entre si. Em SCM estas linhas de
desenvolvimento secundárias são conhecidas como Branches e são usadas em geral para realizar
correções ou pequenas alterações sobre versões congeladas ou liberadas da aplicação, ou para
liberar uma versão especial para um cliente.
O desenvolvimento em cada uma destas development version é independente, tendo cada versão
seus próprios objetos, sua própria base de dados, ambientes para gerar a aplicação, etc.
Uma Development Version, é então, uma cópia da KB editável e independente.

7. Uma Frozen Version permite armazenar de forma estática momentos especiais da KB. É o elemento
que utilizamos para marcar distintos marcos no processo, como por exemplo “feche” uma versão
para liberá-la aos clientes.
Se obtêm a partir de uma versão em desenvolvimento (development version), “congelando-a” para
obter uma “foto” num determinado momento.
A versão obtida é Read Only, que objetos da mesma não poderão ser modificados, nem tampouco
suas propriedades. Sendo possível realizar ações relacionadas com a geração da aplicação, como
por exemplo a criação da base de dados ou a geração novamente dos programas.
Quando congelamos uma versão é porque determinamos que a mesma está em um estado
consistente e seria conveniente guardar dito estado. Por exemplo, congelamos uma version X para
se dar aos clientes, em determinado momento, enquanto o processo de desenvolvimento continua,
um novo cliente requer a aplicação, então o que fazermos é gerar a mesma na version X, que
sabemos que tem um estado correto e a instalamos ao novo cliente.
Se os objetos não poder ser modificados, podem ser abertos para distintas consultas ou para
realizar comparações com outras versões da aplicação.

8. Partimos do nó raiz da árvore de versões, o qual se cria ao criar a KB.
A aplicação vai sofrendo alterações a medida que transcorre o ciclo de desenvolvimento. A linha de
desenvolvimento principal é onde se implementam as funcionalidades requeridas e onde se faz a
prototipação.
Esta linha de desenvolvimento geralmente coincide com o Trunk, ou seja com a ramo principal da
árvore de versões. É uma Development Version criada por default quando a KB é criada.
A medida que as modificações na aplicação são realizadas, a mesma vai se alterando ao longo do
tempo.

10. As Frozen Version servem para:
• Analisar (não modificar) objetos, propriedades, environments, etc.
• Como fonte de um Reporte de Análise de Impacto da base de dados
• Para criar a base de dados
• Para regerar todos os programas

12. Na versão de “Produção” vão sendo produzidas variações devido aos consertos, mas não se agrega
funcionalidades novas. As mesmas são agregadas na linha de desenvolvimento principal.
As Development Version servem para:
- Trabalhar numa linha de desenvolvimento paralela a principal
- Como fonte ou destino de uma operation de Revert a partir de uma Frozen Version de Backup

13. Observe que as Frozen Version mais novas, são mostradas mais acima na árvore de versões.

14. O tempo que se demora em criar uma nova Development Version é proporcional ao tamanho da KB.

15. Como as linhas de desenvolvimento do Trunk (Desenvolvimento) e de Relase 1 (Produção) são
paralelas, as alterações numa não afeta a outra.
Ambas versões são totalmente independentes e podemos requerer congelá-las por diferentes
motivos. Por exemplo, no caso do ramo de Produção, para fixar um estado depois de certos
consertos que tivemos que fazer.
De acordo com a metodologia adotada, no ciclo de desenvolvimento principal, é onde se agregam
novas funcionalidades, consertos, alterações importantes na aplicação, prototipação e testing. É
mais frequente que seja necessária “fotos” nessa etapa viva do desenvolvimento da aplicação.
No ramo do Release1, as alterações são menores, mais certos consertos circunstanciais que não
agregam funcionalidade. Neste caso, é menos frequente a necessidade de criar Frozen Versions,
mas pode ser igualmente necessário.

17. GeneXus gera automaticamente os programas e as estruturas da BD, partindo da versão que esteja
ativa.
Se pode marcar como ativa uma versão em desenvolvimento ou uma versão congelada. Neste
último caso, não poderemos fazer nenhuma modificação a mesma, somente utilizá-la para gerar a
aplicação ou para realizar um impacto na base de dados, ou para comparar versões.
Somente pode ter uma versão ativa por vez.