Как лучше всего обновить версию модулей в многомодульном проекте Maven

Дано: многомодульный проект Maven

Задача: обновлять версию после каждого релиза

Я вижу 2 разные стратегии:

Стратегия 1 — во время обновления: обновлять версии всех модулей вне зависимости от того, были обновления или нет.

Стратегия 2 — минимальное обновление: обновить только те версии тех модулей, которые действительно были затронуты.

Предположим, что у нас есть следующая структура проекта:

root
---dao
---domain
---web
   ---site1
   ---site2
---processors
    ---processor1
        ---processor1Service
        ---processor1Util
        ---processor1Tests
    ---processor2
        ---processor2Service
        ---processor2Util
        ---processor2Tests
---simulators
    ---simulator1
        ---simulator1Service
        ---simulator1Util
        ---simulator1Tests
    ---simulator2
        ---simulator2Service
        ---simulator2Util
        ---simulator2Tests
---etc

все родительские помпоны имеют тип упаковки - пом. Все конечные модули имеют тип производства ресурсов - jar, war, sar и т. д. Корневой pom содержит раздел dependencyManagement, в котором перечислены все дочерние модули.

стратегия 1:

• релиз-менеджер RM (или кто-то еще) объединяет обновления из ветки (ов) «feature»
• происходят все процессы непрерывной интеграции (пусть все в порядке)
• RM вызывает mvn release:versionUpdate -DsetVersion=1.2 в корне
• Выполнено

стратегия 2:

• RM объединяет обновления из ветки (ов) «feature»

• происходят все процессы непрерывной интеграции (пусть все в порядке)

• RM проверяет модули, которые действительно были затронуты, с помощью инструментов Subversion (git, svn и т. д.)
• RM увеличивает версию затронутых модулей вручную
• Выполнено

стратегия 1:

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

1. нет ручного ввода от человека (может быть, кроме номера версии)
2. Конфигурация pom тривиальна и едина, может обрабатываться только на корневом pom с использованием раздела dependencyManagement
3. единая версия всех модулей в результате нет зоопарка версий модулей
4. не нужно зависеть от внешних инструментов, которые должны проверять, где были актуальные обновления (или, что еще хуже, зависеть от внимательности RM)
5. разработчики не ограничены в внесении каких-либо изменений, не связанных с их модулем (например, не нужно бояться, если вы добавите новую строку или случайно запустите инструмент автоматического форматирования в IDE)

недостатки:

1. будут обновлены версии модулей, которые на самом деле не были затронуты - в результате возможна проблема с местом на HDD

стратегия 2:

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

1. будут обновлены версии модулей, которые были фактически обновлены

недостатки:

1. зоопарк версии. dao_1.2 зависит от domain_1.52, оба зависят от модуля etc_1.639
2. ручной ввод
3. зависимость от внешних инструментов, которые должны проверять актуальные обновления

Пожалуйста, поделитесь своим мнением. Как эта проблема решается в крупных проектах, таких как, например. пружинный каркас