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

Учитывая: мультимодульный проект Maven

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

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

стратегия 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

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

---

стратегия 1:

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

стратегия 2:

• RM объединяет обновления из ветки (функций)

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

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

---

стратегия 1:

выгоды:

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

недостатки:

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

стратегия 2:

выгоды:

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

недостатки:

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

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