Changes between Version 16 and Version 17 of Projeto/Versionamento

Timestamp:

11/26/10 14:15:06 (13 years ago)

Author:

niltonneto

Comment:

--

Projeto/Versionamento

@@ -36 +36 @@
 O ciclo rápido de lançamentos foi escolhido como uma forma de trazer novos recursos aos usuários de uma forma estável com o mínimo de atraso possível. Como resultado, o novo código – recursos, drivers de dispositivos etc. – ficaria disponível em um kernel estável com poucos meses de sua conclusão, minimizando ou eliminando a necessidade das distribuições Linux criarem patches para as suas versões estáveis. Assim sendo, os kernels lançados pelas diversas “distLinux” contêm muito poucas modificações específicas da distribuição, rendendo alta estabilidade e poucas diferenças entre distribuições.
 
-[[Image(modelo_figura_1.jpg)]]
+[[Image(modelo_figura_1.gif)]]
 
 Portanto, cada versão 2.6.x é uma versão estável, a qual é liberada quando a lista de grandes bugs se torna tão pequena quanto possível. Se houver problemas logo após um lançamento de kernel, as respectivas correções são rapidamente disponibilizadas para comunidade, através do repositório que contém sua linha principal de desenvolvimento.
@@ -42 +42 @@
 Outro exemplo interessante é o modelo de versionamento do Ubuntu, que lança a cada dois anos uma versão LTS (Long Term Support), e as demais, são lançadas ao longo do tempo, conforme correções e melhorias são concluídas. A diferença entre uma versão normal e uma LTS está no suporte a longo prazo, já que esse último possui três anos – para desktop - e cinco anos – para servidor.
 
-Inserir aqui a figura 2
+[[Image(modelo_figura_2.jpg)]]
 
 Ambos os modelos citados fazem o uso de uma linha principal de desenvolvimento, e de ciclos curtos para lançamento de versões. Além disso, trabalham com branches para suporte posterior das versões lançadas, onde são publicadas as correções de bugs e vulnerabilidadas de segurança.
@@ -61 +61 @@
 Outra diferença está na criação de um branch permanente para cada versão gerada dentro de um ciclo longo, já que as publicadas para a comunidade deverão ter suporte a correções de bugs e vulnerabilidades de segurança, por um período maior de tempo. Melhorias e novas funcionalidades não serão replicadas nesses branches.
 
-Inserir aqui a figura 3
+[[Image(modelo_figura_3.jpg)]]
 
 == O Processo de Testes ==
@@ -75 +75 @@
  4.Criação de uma tag final com mesmo nome do branch criado, para finalizar e aprovar o ciclo de testes.
 
-Inserir aqui a figura 4
+[[Image(modelo_figura_4.jpg)]]
 
 
@@ -91 +91 @@
 Atualmente, a numeração das versões dos pacotes Expresso Livre, incluindo API e seus módulos, baseia-se na seguinte definição:
 
-Inserir aqui a figura 5
+[[Image(modelo_figura_5.jpg)]]
 
 Este padrão de numeração é bastante simples, mas não atende às empresas que participam do desenvolvimento do Expresso. Muitas delas, trabalham na manutenção e no suporte de versões customizadas ao longo do tempo, para seus clientes, e precisam de mais informações sobre qual versão exata está implantada em um determinado cliente.