Как я могу автоматически обновлять Perl-модули $VERSION с помощью Git?

Скажем, команда программистов делает веб-приложение в Perl и использует git для размещения своего кода. Теперь у них есть небольшая проблема с версией модулей:

Perl::Critic и PBP рекомендуют RCS -backed $VERSION переменная в коде
git явно рекомендует против использовать заменяемые номера версий в коде (с хорошими рассуждениями)

Я понимаю, почему git не выполняет расширение ключевого слова. Тем не менее, я прекрасно понимаю необходимость номеров версий для небольшого кода:

Для do требуется отдельное управление версиями для каждого модуля, так как вы можете использовать версию use
Возможно, вы не хотите изменить эти номера версий для быстро изменяющегося модуля вручную

Глобальная версия продукта для упаковки и тестирования может быть легко реализована с помощью тегов и git describe, но я до сих пор не вижу возможности внедрить автоматическое управление версиями для отдельных модулей.

У вас есть решение для меня?

Ответ 1

Забудьте, что Perl Best Practices говорит. Это не библия, а просто предлагает использовать ключевые слова RCS, потому что в то время, когда было написано, никто не думал о других системах управления версиями. Ваша цель никогда не должна соответствовать конкретной реализации PBP, но приспосабливая идеи в PBP к вашей собственной ситуации. Не забудьте прочитать первую главу этой книги.

Прежде всего, исправьте свои предположения:

Вам не нужна отдельная версия для каждого модуля в дистрибутиве. Вам нужно всего лишь предоставить каждому модулю версию, отличную от версии в предыдущих дистрибутивах. Каждый модуль в дистрибутиве может иметь одну и ту же версию, и когда они это делают, все они могут быть больше, чем версия из последнего дистрибутива.
Почему бы не изменить версии быстро изменяющегося модуля вручную? Вы должны были определить точки, где ваш код становится тем, что люди могут использовать. В этих случаях вы делаете что-то, чтобы сказать, что вы приняли решение о том, что ваш рабочий продукт должен быть распространен, будь то тест или стабильный выпуск. Вы меняете версии как способ рассказать людям о своем развитии. Когда вы позволяете системе управления версиями делать это только потому, что вы совершаете, вы теряете возможность обозначать циклы в своем развитии. Например, я обычно использую два небольших релиза. Это означает, что я получаю 100 выпусков до того, как сортировка закончится из-за wack, и мне нужно поднять основную версию, чтобы восстановить правильный порядок сортировки. Этого недостаточно, если я позволю VCS справиться с этим для меня.

Я использовал ключевые слова RCS, чтобы связать версии моих модулей с их номером проверки или пересмотра, но мне это никогда не нравилось. Я делаю много коммитов в файл, прежде чем он будет готов к следующей версии, и мне не нужно менять $VERSION только потому, что я исправил опечатку документации. Были бы большие прыжки в номерах версий, потому что у меня было много небольших изменений.

Теперь я просто изменяю версии всех моих файлов модулей, когда я готов выпустить новый дистрибутив. Я использую ppi_version, чтобы сразу изменить все версии:

ppi_version change 1.23 1.24

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

Если я работаю над новым дистрибутивом из версии 1.23, я начинаю создавать версии разработки 1.23_01, 1.23_02 и т.д., но только тогда, когда я готов позволить людям попробовать эти версии. Я меняю версию в начале цикла, а не на конец. Все мои коммиты, ведущие к следующему выпуску, уже имеют следующую версию. Я также делаю заметки о том, что я хочу, чтобы этот цикл выполнялся.

Когда я думаю, что это начало нового цикла, я снова использую версию. Когда я думаю, что у меня стабильный выпуск, я меняю разработку $VERSION на стабильную, например, с 1.23_04 до 1.24. Всякий раз, когда я что-то выпускаю, я также помещаю его в исходный элемент управления. Я могу видеть, где мои основные моменты развития выстраиваются в очередь с контролем источника довольно легко.

Для меня все намного проще. Ничто не привязано к исходному элементу управления, который я решил использовать, поэтому мне не нужно переделывать все, если я изменю то, что я использую.

Ответ 2

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

Вы также можете проверить man-страницу gitattributes 'для атрибута filter - возможно, вам захочется представить свою собственный фильтр для выполнения замещений на основе " git описать 'вывод автоматически.

Ответ 3

Что вы используете для создания своего модуля Perl?

Решение, используемое ядром Linux и самим проектом Git, заключается в замене "++ VERSION ++" (или "++ PROJECT_VERSION ++" или "@@PROJECT_VERSION @@" ) заполнителями системой сборки, в этом случае Makefile. (В файлах в C это делается путем определения константы препроцессора PROJECT_VERSION, через опцию '-DPROJECT_VERSION=$(PROJECT_VERSION)', переданной компилятору). В вашем случае это может быть что-то вроде Module::Install, Module::Build или ExtUtils::MakeMaker.

Оба ядра Git ans Linux используют для этого GIT-VERSION-GEN script который:

использует git describe, если проект построен из репозитория Git,
возвращается к version (или version или GIT-VERSION-FILE) файлу, если сборка выполняется из моментального снимка (этот файл создается при создании моментального снимка/архива),
и, наконец, возвращается к предварительно определенному номеру версии, номер которого обновляется в commit, который отмечает новую выпущенную версию (например, cb572206 зафиксировать в репозитории Git, aka commit v1.6.4.4).

Я надеюсь, что это вам поможет.

Ответ 4

Как насчет чего-то действительно ленивого, что только немного грязно:

Вы можете написать крошечную оболочку для git-add. Перед тем, как на самом деле вызвать git-add, обертка будет подталкивать номер версии где-нибудь в модуле, где его можно найти с помощью простого регулярного выражения.

Update:

В настоящее время я не использую что-то подобное, но я серьезно об этом думаю.

Мое текущее рассуждение:

В отличие от CVS или subversion, git ничего не знает о версиях или номерах версий.
У драйверов фильтров должен быть другой источник информации, чтобы иметь возможность вставлять номер версии, и этот источник должен быть доступен на компьютере любого из разработчиков.
Таким образом, лучшим источником для номера версии является сам файл с версией.
И для того, чтобы сам файл использовался в качестве источника для следующего номера версии, номер версии должен быть частью соответствующего git blob.

Преимущества:

Это так же автоматически, как и получается, нет способа забыть обновить номер версии.
Плавный переход от CVS/SVN к git. Каждая команда вводит новую версию.

Недостатки:

Ленивый разработчик, который всегда делает git add ., будет подталкивать номера версий файлов, которые он не касался.
Кажется, что нет способа принудительного использования оболочки script.