Забудьте, что Perl Best Practices говорит.Это не Библия, а просто предлагает использовать ключевые слова RCS, потому что в то время, когда она была написана, никто не думал о других системах контроля версий.Вашей целью никогда не должно быть соответствие конкретной реализации PBP, а адаптация ideas в PBP к вашей собственной ситуации.Не забудьте прочитать первую главу этой книги.
Сначала давайте исправим ваши предположения:
Вам не нужна отдельная версия для каждого модуля в дистрибутиве.Вам нужно только дать каждому файлу модуля версию, отличающуюся от предыдущей версии.Каждый модуль в дистрибутиве может иметь одну и ту же версию, и когда они это делают, все они могут быть больше, чем версия из последнего дистрибутива.
Почему бы не изменить версии быстроменять модуль вручную?Вы должны были определить точки, где ваш код становится тем, что люди могут использовать.В этот момент вы делаете что-то, чтобы сказать, что вы приняли решение о том, что ваш рабочий продукт должен распространяться, будь то тестовый или стабильный выпуск.Вы изменяете версии как способ рассказать людям о своей разработке.Когда вы позволяете системе контроля версий делать это только потому, что делаете это, вы теряете возможность обозначать циклы в своей разработке.Например, я обычно использую два небольших места выпуска.Это означает, что я получаю 100 выпусков до того, как сортировка выйдет из строя, и мне нужно поднять основную версию, чтобы восстановить правильный порядок сортировки.Недостаточно места для версии, если я позволю 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.Всякий раз, когда я выпускаю что-то, я также отмечаю это в управлении исходным кодом.Я могу видеть, где мои основные точки развития довольно легко совмещаются с контролем версий.
Для меня все намного проще.Ничто не связано с управлением исходным кодом, которое я решил использовать, поэтому мне не нужно переделывать все, если я изменяю то, что я использую.