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

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

9 голосов
/ 12 июня 2009

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

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

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

GIT используется в качестве VCS.

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

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

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

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

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

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

THX.

Ответы [ 3 ]

10 голосов
/ 19 июля 2009

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

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

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

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

6 голосов
/ 12 июня 2009

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

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

Обе они основаны на хранении номера версии в файле где-то в вашем исходном дереве.

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

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

1 голос
/ 12 июня 2009

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

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

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

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

...