Qual A Versão Considerada Estável Do Acbr ?

[Clayton Alves]

Gostaria de saber qual é a última versão considerada estável do ACBr ?

 

Pergunto isso pois, na pasta tags do repositório do projeto, o último commit foi do dia 23/05/2012. Aparentemente a pasta não está sendo usada para listar as tags corretamente, ou faz muito tempo que não sai um release.

 

No arquivo leiame retirado do trunk, consta que a versão é a 0.9.0b  ... ou seja, beta.

 

Qual seria a versão mais estável ?

[Daniel Simoes]

http://www.projetoacbr.com.br/forum/index.php?/forum-3/announcement-2-novo-caminho-para-o-c%C3%B3digo-fonte-do-acbr-no-sourceforge/

[Clayton Alves]

Olá Daniel,

 

Eu utilizou o projeto ACBr através do repositório atualizado (https://svn.code.sf.net/p/acbr/code). Como mencionei anteriormente, o último release da pasta tag do repositório é de 2009 (versão 0.8.8).

 

Neste link que você encaminhou, existem links para o projeto no sourceforge onde é possível fazer download do instalador do ACBr, que estão bem defasados também.

 

Pelo que entendi, o projeto ACBr é rolling release, ou seja, não possui versões que marquem etapas definidas do projeto. Me corrija se eu estiver errado.

 

Se realmente o projeto é rolling release, gostaria de saber se existe garantia de que o código em /trunk é sempre compilável, pois como existem vários colaboradores que commitam no repositório principal, pode existir casos em que alguém suba código quebrado para /trunk. Se eu atualizar o reporsitório aqui e fizer o build do projeto quebrado, como posso saber se o problema é no meu ambiente ou no próprio projeto?

[EMBarbosa]

Olá Daniel,

 

Eu utilizou o projeto ACBr através do repositório atualizado (https://svn.code.sf.net/p/acbr/code). Como mencionei anteriormente, o último release da pasta tag do repositório é de 2009 (versão 0.8.8).

 

Neste link que você encaminhou, existem links para o projeto no sourceforge onde é possível fazer download do instalador do ACBr, que estão bem defasados também.

 

Pelo que entendi, o projeto ACBr é rolling release, ou seja, não possui versões que marquem etapas definidas do projeto. Me corrija se eu estiver errado.

 

Se realmente o projeto é rolling release, gostaria de saber se existe garantia de que o código em /trunk é sempre compilável, pois como existem vários colaboradores que commitam no repositório principal, pode existir casos em que alguém suba código quebrado para /trunk. Se eu atualizar o reporsitório aqui e fizer o build do projeto quebrado, como posso saber se o problema é no meu ambiente ou no próprio projeto?

 

Olá Clayton,

 

   Não temos feito tags visto que a gama de componentes é muito grande e eles estão seguindo no momento numeração de verões independentes.

   Como desenvolvedores procuramos tomar muito cuidado com isso. Principalmente pois somos os principais usuários dos componentes units e classes. Infelizmente, devido a sermos imperfeitos, pode realmente passar um commit que vá com algum erro. Mas normalmente quando alguém faz isso, logo em seguida ou a mesma pessoa ou outro desenvolvedor vê o erro e corrige. O maior tempo que eu vi um erro ficar no trunk foi 24 horas.

   Ainda assim, nós sugerimos que os usuários do ACBr sempre acompanhem os arquivos changelog e o log do SVN para entenderem as modificações que estão sendo feitas. Os componentes são bem dinâmicos e os desenvolvedores muito ativos, assim sempre temos algo novo. Isso é muito bom, mas pode ter um efeito indesejado em algumas situações. Por exemplo, talvez uma modificação para atender uma legislação nova pode quebrar a compatibilidade com uma funcionalidade antiga que você ainda esteja utilizando nos clientes no momento e não pode alterar.

   Aqui na empresa nós adotamos o costume de trabalhar com uma revisão específica pra facilitar. Daí, de forma quase diária, analisamos as revisões novas antes de atualizar o repositório local.

[Juliomar Marchetti]

Completado ao Elton!

caso tenha problemas, é fácil montar um script que faz um backup antes de fazer o update do svn!

então veja as possibilidades são muitas! e reforçando efetuamos testes com os códigos antes de subir, visto que por exemplo para alguns casos temos que compilar 2 vezes

para capcom e openssl