Camaradas:

Gostava de colocar à discussão este tema.

Num projecto em que tenho trabalhado, até ao momento, optamos (por simplificação) por definir as versões das nossas assemblies estaticamente 1.0.0.0.0. Se me recordo correctamente, o VS 2005 sugere isto por defeito por oposição às versões anteriores que sugeriam um versionamento do tipo 1.0.*.*.

A questão que se coloca agora é que temos tido algumas dificuldades porque na realidade acabamos por ter várias builds diferentes em que as assemblies têm versões iguais.

Analisando esta questão, surgem-me várias dúvidas sobre as quais gostaria de ouvir as vossas opiniões/experiências:

• Assumindo um esquema incremental de versionamento, o que preferem? Versões incrementais (tipo 1.0.0.1, 1.0.0.2, etc.) ou versões baseadas na data da build (1.0.70101.1, 1.0.70101.2, 1.0.70102.1, etc.)?
• Como tratar esta questão no processo de builds do TSF (msbuild)?
• Automatizando o versionamento nas builds, como tratar a questão do source control?
• E as dependências entre projectos (quer a nível de referências como a nível de ficheiros de configuração que referem assemblies directamente com o número da versão)? Isto vai ligar de certo com um esquema de binding redirect mais ou menos complexo.

Um dos aspectos cruciais é que a equipa de desenvolvimento não deveria ter nenhuma intervenção no processo (daí a automatização no processo de build) mas também não deve ter que pagar nenhum custo por este processo existir (exemplo: ter cuidados adicionais para ir buscar as versões correctas de determinados projectos ou ficheiros).

Pessoalmente, pensei até agora que poderiamos viver bem com uma versão estática. E também não fui capaz de encontrar documentação de referência sobre este assunto que vá para além de explicar o versionamento do .NET ou custom tasks para o msbuild (que só resolvem parte do problema).

Será que estou a ver esta questão da maneira errada ou deveria existir já trabalho de referência público sobre esta matéria?

Agradeço os vossos comentários.
 

Caro Hgr,

Eu gosto particularmente do sistema de versionamento de plugins do eclipse http://wiki.eclipse.org/index.php/Version_Numbering

Não estou de acordo contigo quando dizes que a equipa de desenvolvimento não deveria ter nenhuma intervenção no processo. Claro que para fazer esta afirmação parto do principio que a equipa de desenvolvimento é composta por Programadores e não de tradutores ou codificadores de ecrãs.

José Formiga

Ola Hugo,

 Eu trabalho sempre com AssemblyVersion estático, mas com FileVersion incremental. Isto parece-me resolver também todas as questões que referes.

Significa isto que o assemblyversion é alterado de iteração para iteração (ou release para release, como preferires), mas as builds diárias, continuas, etc, são reflectidas no fileversion. Também uso isto para patchs, ou seja, se não tenho uma release completa, liberto um patch com fileversion, de forma a manter a triagem mas garantindo que nada é quebrado.

Em relação ao source control, por norma nunca coloco o sistema de builds, integração continua ou outro, a fazer checkins no repositorio, exceptuando o output da build em folder proprio.

Que tal?

um abraço

Obrigado pelo link. Não conhecia. Esta abordagem é interessante na perspectiva de gerir a "alteração manual" dos elementos da versão.

No entanto, a questão fundamental de gerir o processo automaticamente nas builds permanece.

Uma nota apenas sobre o meu comentário de que a equipa de desenvolvimento não deve ter intervenção no processo. Isto refere-se exactamente ao processo automático de versionamento nas builds. Aquilo que me parece é que a equipa (alguém na...) deve decidir quando mudam os valores superiores (com regras tipo as definidas para o Eclipse). Porém para o valor indexado à build tem que ser automático (temos N builds diárias) e não deve obrigar ninguém na equipa de desenvolvimento a ter que fazer qualquer coisa localmente para a última versão do código funcionar. Este era o meu ponto.

Obrigado.

 

Hugo Pais Batista:

Ola Hugo,

 Eu trabalho sempre com AssemblyVersion estático, mas com FileVersion incremental. Isto parece-me resolver também todas as questões que referes.

Significa isto que o assemblyversion é alterado de iteração para iteração (ou release para release, como preferires), mas as builds diárias, continuas, etc, são reflectidas no fileversion. Também uso isto para patchs, ou seja, se não tenho uma release completa, liberto um patch com fileversion, de forma a manter a triagem mas garantindo que nada é quebrado.

Em relação ao source control, por norma nunca coloco o sistema de builds, integração continua ou outro, a fazer checkins no repositorio, exceptuando o output da build em folder proprio.

Que tal?

um abraço

Ora aqui está uma abordagem que não me tinha passado pela cabeça. :)

Duas perguntas adicionais:

• Como é que o processo de builds actualiza a FileVersion? Usando apenas o assembly: AssemblyFileVersion, certo?
• Quando há uma nova release, incrementas a AssemblyVersion. Portanto, tens que gerir manualmente também as referências para essas assemblies, bem como ficheiros de configuração, etc.?

Vou experimentar esta abordagem.

Obrigado Hugo! 

hgr:

Ora aqui está uma abordagem que não me tinha passado pela cabeça. :)

Duas perguntas adicionais:

• Como é que o processo de builds actualiza a FileVersion? Usando apenas o assembly: AssemblyFileVersion, certo?
• Quando há uma nova release, incrementas a AssemblyVersion. Portanto, tens que gerir manualmente também as referências para essas assemblies, bem como ficheiros de configuração, etc.?

Vou experimentar esta abordagem.

Obrigado Hugo! 

Sim, actualizo o AssemblyFileVersion.

Em cada release mando o output para um folder do source control que tem o id da versao. Cada equipa tem a responsabilidade de no final da sua release começar a usar a nova release dos assemblies partilhados.

Em ficheiros de configuração uso uma coisa completamente diferente. Digamos que idealmente nunca preciso de colocar a versao hardcoded em configuração, dado o meu sistema de carregamento de assemblies dinamico.

um abraço