Как я могу автоматически обновлять 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.