Colidindo números de versão para novos lançamentos em arquivos associados (documentação)

Question

Eu estaria interessado em em saber como você lá fora, lidar com o batendo o número da versão para emissão novos lançamentos.

Como você lida com o número da versão em arquivos associados, como páginas de manual, etc.

O software é construir com a cadeia de ferramentas GNU tão autoconf, automake, etc estão disponíveis e usado para o número da versão do aplicativo. Para que as informações possam ser reutilizados.

git é usado como um vcs.

Uma possibilidade seria introduzir um extra, novo alvo em Makefile.am que faz um sed / awk para substituir o número da versão e as datas em todos os arquivos associados. Essa meta poderia ser chamado uma vez no início (logo após ramificação) do desenvolvimento de uma nova versão.

Em seguida, o projeto poderia construir com as informações corretas quando as pessoas faria um git clone do projeto ou quando um arquivo tar liberação é feito. Claro que tem de se lembrar de executar este alvo make quando se inicia o desenvolvimento de uma nova versão.

Outra opção seria fazer a substituição do sed / awk com um gancho para o dist target.But isso seria colocar o repositório git do projeto em um estado não eram número da versão correta é associado com os arquivos associados.

Eu prefiro fazer a primeira solução, uma vez que também registra o correta número da versão dentro da história git.

Ao fazer uma sed / awk substituição você prefere fazê-lo "in-file" ou com um modelo in-file liek o autoconf / automake ferramentas fazer. Vejo vantagens e desvantagens em ambos os métodos.

Como você lida com versionamento de arquivos associados. Você mudá-los no início da fase de desenvolvimento, você mudá-los quando pouco antes de transporte , você faz a substituição infile ou você prefere usar um modelo?

THX.

Answer 1

Eu acho que a maneira padrão de fazer isso é usar o sistema de gancho do Git e M4 ou sed / awk para fazer a pesquisa / substituir como você sugere. Você só precisa de um símbolo especial com em um comentário em cada arquivo (provavelmente no cabeçalho).

Aqui é a referência sobre githooks e é aqui algumas páginas escritas por pessoas resolvendo o mesmo problema :

• http://groups.google.com/group/memcached/browse_thread / thread / b02e992ede0f0e89
• http: //blog.rfwatson. net / 2009/06/03 / automático-version-numeração utilizando-git /

Ambos dependem de armazenar o número da versão em algum lugar do arquivo na sua árvore fonte.

Eu também veio através de um tomou chamado 0release que as reivindicações para automatizar a criação de libertação (e números de versão de configuração ).

Finalmente, quanto os números de versão, este é abordada em várias outras perguntas:

• Qual versão numeração esquema que você recomendaria?
• Como você faz numeração versão em um ágil projeto?
• Qual versão esquema de número para o mal planejada , ramificado, e aplicação esquizofrênico
• E mais https://stackoverflow.com/search?q=release+numbering

Answer 2

Uma solução comum hoje em dia é invocar AC_INIT com um argumento m4_esyscmd para gerar a versão a partir git. Por exemplo, configure.ac do autoconf contém as linhas:

AC_INIT([GNU Autoconf],
        m4_esyscmd([build-aux/git-version-gen .tarball-version]),
        [bug-autoconf@gnu.org])

onde build-aux / git-version-gen é um script simples que as chamadas 'git descrever' para gerar o número da versão. (Veja gnulib)

Há desvantagens para esta abordagem, mas pode ser eficaz.

Answer 3

Nós usamos o sistema major.minor.patch clássico, que é aplicado para liberar candidatos como um 'tag', temos um script que é marcado para um commit como o número da versão, em vez de usar um git 'tag objeto'. Toda a numeração versão é feita 'à mão'. Ele funciona razoavelmente bem, porque o número da versão é criado pelo 'liberação no estadiamento scripts', que é muito mais tarde no processo de desenvolvimento. Não se incomode com qualquer um dos ganchos git, porque nós realmente não precisa, se uma consolidação não é sair do ambiente de desenvolvimento, então ele não precisa id diferente do que do código SHA interno.

Nós tentar impor que cada release 'remendo' deve ser binário compatível com outras versões com o mesmo maior, menor tag.

Dessa forma, qualquer coisa com um tag deve pelo menos construção, mas é possível ou muito provável que não vai funcionar para spec.

Um refinamento seria fazer com que o departamento de QA para criar um objeto tag assinado em tudo o que é 'QA aprovado', mas por agora contamos com outros documentos para isso.