Как я могу автоматически обновить $VERSION модулей Perl с Мерзавцем?

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

Во-первых, давайте исправим ваши предположения:

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

2. Почему бы не изменить версии быстро меняющегося модуля вручную? Вы должны определить точки, в которых ваш код станет чем-то, что люди смогут использовать. В эти моменты вы делаете что-то, чтобы сказать, что вы приняли решение распространять свой рабочий продукт, будь то тестовый или стабильный выпуск. Вы меняете версии, чтобы рассказать людям что-то о своем развитии. Когда вы позволяете системе управления версиями делать это только потому, что вы совершаете коммит, вы теряете шанс обозначить циклы в вашей разработке. Например, я обычно использую двухместные второстепенные релизы. Это означает, что я получаю 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. Каждый раз, когда я что-то выпускаю, я тоже помечаю это в системе контроля версий. Я довольно легко вижу, где мои основные моменты разработки совпадают с контролем версий.

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