[sapl-dev] Melhorias no můdulo Parlamentar - SAPL 2.3

Angelo Marcondes de Oliveira Neto angelomarcondes em gmail.com
Segunda Maio 9 15:11:54 BRT 2011


Bem,

Assim sendo e diante dos fatos, eu concordo e assino em baixo.

abraços

Angelo Marcondes de Oliveira Neto.
http://uaigeek.blogspot.com
angelomarcondes em gmail.com
(34) 91414287 - Linux User: #417837
Carneirinho - MG


Em 9 de maio de 2011 14:31, Luciano De Fazio <lucianodefazio em gmail.com>escreveu:

> √āngelo,
>
> Segue relação dos commits feitos no ano de 2011.
>
>
> http://colab.interlegis.gov.br/log/ILSAPL?action=stop_on_copy&mode=stop_on_copy&rev=5022&stop_rev=&limit=225
>
> Acho que isso responde √° sua pergunta.
>
> Quando uma versão é considerada estável, na minha opinião derveria sim ser
> congelada, principalmente num ambiente colaborativo desprovido de processo
> de homologação / validação do código em tempo real.
>
> []'s
>
> Luciano De F√°zio
>
>
> Em 9 de maio de 2011 14:18, Angelo Marcondes de Oliveira Neto <
> angelomarcondes em gmail.com> escreveu:
>
> Luciano,
>>
>>
>> Muito interessante a sua proposta.
>> Mas aí entro com um questionamento? Será que já temos uma produção de
>> código tão extensa que necessite deste congelamento?
>>
>> Abraços
>>
>> Angelo Marcondes de Oliveira Neto.
>> http://uaigeek.blogspot.com
>> angelomarcondes em gmail.com
>> (34) 91414287 - Linux User: #417837
>> Carneirinho - MG
>>
>>
>> Em 9 de maio de 2011 12:46, Luciano De Fazio <lucianodefazio em gmail.com>escreveu:
>>
>> Jean,
>>>
>>> Estive lendo v√°rios documentos sobre conceitos e boas pr√°ticas de SVN.
>>>
>>> Segundo alguns desses documentos, o conceito de braches importa no
>>> congelamento do código, ao ser lançada como uma versão, não sofrendo mais
>>> altera√ß√Ķes, mas somente corre√ß√Ķes, ap√≥s rigorosos testes de valida√ß√£o,
>>>
>>> Não seria interessante aplicar alguma política de "congelamento" dos
>>> braches ??
>>>
>>> Por exemplo, após a versão do SAPL 2.3, ninguém mais poderia commitar
>>> nesse branch, senão o responsável pela validação e exclusivamente correção
>>> de eventuais bugs.
>>>
>>> Isso significaria uma validação mais consistente do código, mantendo-se a
>>> estabilidade do sistema.
>>>
>>> Eventuais melhorias e novas funcionalidades dentro de uma mesma vers√£o
>>> m√©dia, ficariam reservadas somente para as tags (vers√Ķes menores).
>>>
>>> Assim, o usu√°rio de uma Casa Legislativa teria duas alternativas ao
>>> atualizar via SVN:
>>>
>>> 1- utilizando simplesmente o "svn up", para obter as poss√≠veis corre√ß√Ķes
>>> homologadas naquele branch considerado est√°vel / congelado; ou,
>>>
>>> 2 -  caso queira obter alguma nova funcionalidade desenvolvida em tags,
>>> seria necessário reapontar sua cópia de trabalho para depois rodar o "svn
>>> up".
>>>
>>> A adoção desse conceito, traria vantagens como:
>>>
>>> - maior controle sobre o código implementado pelos colaboradores da
>>> comunidade,
>>>
>>> - a possibilidade de reapontamento para o branch, em caso de problemas,
>>> para retorno ao código estável
>>>
>>> - a garantia de que o branch ser√° realmente est√°vel.
>>>
>>> []'s
>>>
>>> Luciano De F√°zio
>>>
>>>
>>> Em 9 de maio de 2011 12:08, Jean Rodrigo Ferri <
>>> jeanferri em interlegis.gov.br> escreveu:
>>>
>>> Em 03-05-2011 12:02, Luciano De Fazio escreveu:
>>>> > Perfeito, Jean.
>>>>
>>>> Ol√° Luciano,
>>>>
>>>> > Realmente, é necessário convencionarmos a organização do código no
>>>> > repositório.
>>>> >
>>>> > Nossos logins (comunidade) tem os direitos para cria√ß√£o de vers√Ķes
>>>> menores
>>>> > no subversion? (2.3.1, 2.3.2 ?)
>>>>
>>>> Sim, podem realizar qualquer alteração no nosso SVN.
>>>>
>>>> > Aproveitando sua boa vontade, teria como exemplificar como é que de
>>>> > adicionam as tais vers√Ķes menores?
>>>>
>>>> O trunk tem sempre vers√Ķes maiores (1.0, 2.0) ou m√©dias (2.1, 2.2, 2.3).
>>>>
>>>> Os branchs tem no seu nome sempre a versão média
>>>> (http://repositorio.interlegis.gov.br/ILPortalCasas/branches/1.1/), mas
>>>> como eles s√£o destinados a vers√Ķes est√°veis, que √© justamente a vers√£o
>>>> menor, essa versão é alterada somente no arquivo version.txt, mantendo o
>>>> diretório sempre com o mesmo nome (versão média). Isso garante que o
>>>> usu√°rio atualize se sistema est√°vel simplesmente rodando 'svn up', sem
>>>> ter que reapontar a cópia de trabalho.
>>>>
>>>> Os tags s√£o sempre marcados com vers√£o menor (2.2.1, 2.2.2) pois se
>>>> referem às releases do sistema
>>>> (http://repositorio.interlegis.gov.br/ILPortalCasas/tags/1.0.1/).
>>>>
>>>> Lembrando que para fazer um novo branch ou tag usa-se o comando 'svn
>>>> cp'.
>>>>
>>>> Abraço,
>>>>
>>>> --
>>>> Jean Ferri
>>>> Analista de Sistemas
>>>> Interlegis - Brasília (DF)
>>>> --
>>>> Wiki do SAPL:
>>>> http://colab.interlegis.gov.br/wiki/ProjetoSapl
>>>>
>>>> Regras de participação:
>>>> http://colab.interlegis.gov.br/wiki/ComoParticiparComunidade
>>>>
>>>> Para administrar sua conta visite:
>>>> http://listas.interlegis.gov.br/mailman/listinfo/sapl-dev
>>>>
>>>
>>>
>>> --
>>> Wiki do SAPL:
>>> http://colab.interlegis.gov.br/wiki/ProjetoSapl
>>>
>>> Regras de participação:
>>> http://colab.interlegis.gov.br/wiki/ComoParticiparComunidade
>>>
>>> Para administrar sua conta visite:
>>> http://listas.interlegis.gov.br/mailman/listinfo/sapl-dev
>>>
>>
>>
>> --
>> Wiki do SAPL:
>> http://colab.interlegis.gov.br/wiki/ProjetoSapl
>>
>> Regras de participação:
>> http://colab.interlegis.gov.br/wiki/ComoParticiparComunidade
>>
>> Para administrar sua conta visite:
>> http://listas.interlegis.gov.br/mailman/listinfo/sapl-dev
>>
>
>
> --
> Wiki do SAPL:
> http://colab.interlegis.gov.br/wiki/ProjetoSapl
>
> Regras de participação:
> http://colab.interlegis.gov.br/wiki/ComoParticiparComunidade
>
> Para administrar sua conta visite:
> http://listas.interlegis.gov.br/mailman/listinfo/sapl-dev
>
-------------- Průxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.interlegis.gov.br/pipermail/sapl-dev/attachments/20110509/3cf32a72/attachment.htm 


Mais detalhes sobre a lista de discuss„o SAPL-dev