Увеличение номеров версий для новых выпусков в связанных файлах (документация)

Мне было бы интересно узнать, как вы справляетесь с проблемой увеличения номера версии для новых выпусков.

Как вы обрабатываете номер версии в связанных файлах, таких как страницы руководства и т. Д.

Программное обеспечение построено с помощью цепочки инструментов gnu, поэтому доступны autoconf, automake и т. Д., Которые используются для номера версии приложения. Так что эту информацию можно использовать повторно.

git используется как vcs.

Одна из возможностей - ввести дополнительную, новую цель в Makefile.am, которая выполняет sed / awk для замены номера версии и дат во всех связанных файлах. Эта цель может быть вызвана один раз в начале (сразу после разветвления) разработки нового выпуска.

Тогда проект может быть собран с правильной информацией, когда люди будут выполнять git clone проекта или когда готовится архив релиза. Конечно, нужно не забывать запускать эту цель make перед началом разработки нового выпуска.

Другой вариант - выполнить замену sed / awk с помощью перехватчика для цели dist, но это поставит репозиторий проекта git в состояние, когда с соответствующими файлами не связан правильный номер версии.

Я предпочитаю использовать первое решение, так как оно также записывает правильный номер версии в истории git.

Когда вы выполняете замену sed / awk, предпочитаете ли вы делать это «в файле» или с шаблоном в файле, который делают инструменты autoconf / automake. Я вижу как преимущества, так и недостатки в обоих методах.

Как вы обрабатываете управление версиями связанных файлов. Вы меняете их в начале фазы разработки, меняете ли вы их непосредственно перед отправкой, выполняете ли вы замену в файле или предпочитаете использовать шаблон?

СПАСИБО.


linux autotools version-control build-automation gnu
person f.ederi.co    schedule 12.06.2009    source источник
comment
На самом деле это 2 вопроса, вы можете разделить их более четко.   -  person Dana the Sane    schedule 12.06.2009

Ответы (3)


arrow_upward
6
arrow_downward

Я думаю, что стандартный способ сделать это - использовать систему ловушек Git и m4 или sed / awk для выполнения поиска / замены, как вы предлагаете. Вам просто нужен специальный токен в комментариях к каждому файлу (возможно, в заголовке).

Вот ссылка на githooks и несколько страниц, написанных людьми, решающими ту же проблему:

Оба они полагаются на сохранение номера версии в файле где-нибудь в дереве исходных текстов.

Я также нашел вариант под названием 0release, который утверждает, что автоматизирует создание выпусков (и установку номеров версий).

Наконец, что касается номеров выпусков, это решается несколькими другими вопросами:

person Dana the Sane    schedule 12.06.2009
comment
Я видел другие вопросы. И мой вопрос не столько о схеме для использования, сколько о техническом решении для получения номера версии в связанных файлах приложения, которое получает номер версии из configure.ac, где номер версии находится в источнике. дерево. THX за подсказку с githook. Это избавит от ручного запуска make-файла и наличия дополнительной цели в Makefile.am. Я также посмотрю на 0release. - person f.ederi.co; 12.06.2009

arrow_upward
10
arrow_downward

В настоящее время распространенным решением является вызов AC_INIT с аргументом m4_esyscmd для генерации ВЕРСИИ из git. Например, файл configure.ac autoconf содержит следующие строки:

AC_INIT([GNU Autoconf],
        m4_esyscmd([build-aux/git-version-gen .tarball-version]),
        [[email protected]])

где build-aux / git-version-gen - простой скрипт, который вызывает git describe для генерации номера версии. (см. гнулиб)

У этого подхода есть недостатки, но он может быть эффективным.

person William Pursell    schedule 18.07.2009
comment
Какие недостатки ты мог бы придумать, Уильям? - person f.ederi.co; 20.07.2009
comment
Главный недостаток - это расходы, связанные с увеличением номера версии. Чтобы распространить изменение на код, вам необходимо повторно запустить цепочку autotool, что вызовет повторную компиляцию всех исходных файлов, включающих config.h, поэтому в основном это означает перестройку всего проекта. Поскольку версия поступает из репозитория git, это означает, что каждая фиксация вызывает перестройку. Текущая модель, используемая в autoconf, работает вокруг этого, распространяя изменение только в make dist или make distcheck через некоторые правила в файле GNUmakefile. Решения обсуждаются в списках автоинструментов. - person William Pursell; 21.07.2009

arrow_upward
1
arrow_downward

Мы используем классическую систему major.minor.patch, которая применяется к кандидатам на выпуск в качестве «тега», у нас есть сценарий, который помечает фиксацию как номер версии, а не использует git «объект тега». Вся нумерация версий производится «вручную». Он работает достаточно хорошо, потому что номер версии создается сценариями «выпуска на промежуточную стадию», что происходит гораздо позже в процессе разработки. Мы не беспокоимся об использовании каких-либо хуков git, потому что нам это действительно не нужно, если коммит не покидает среду разработки, тогда ему не нужен идентификатор, кроме внутреннего кода SHA.

Мы стараемся обеспечить, чтобы каждый выпуск «патча» был двоично совместим с другими версиями с тем же основным, второстепенным тегом.

Таким образом, все, что имеет тег, должно быть как минимум построено, но вполне возможно или весьма вероятно, что это не будет работать в соответствии со спецификацией.

Уточнение могло бы заключаться в том, чтобы отдел QA создавал объект подписанного тега для всего, что «одобрено QA», но пока мы полагаемся на другие документы для этого.

person Chris Huang-Leaver    schedule 12.06.2009