maven - версионирование мульти-модульных проектов

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

Можно указать диапазон версий для артефакта:

        <dependency>
            <groupId>some.group</groupId>
            <artifactId>some.name</artifactId>
            <version>[1.0.0,1.1.0)</version>
        </dependency>

недостаток: если будет много версий одного артефакта, то их POM-файлы будут подтягиваться все из репозитория при каждой сборке, что некисло замедляет сборку. мы просто ограничиваем нижнюю границу версий, например:

            <version>[1.0.200,1.1.0)</version>

В любом случае, правила использования диапазонов версий выработаете уже потом сами по договорённостям внутри команды.

dependencyManagement?

Последняя версия самая нормальная. Но обычно никто не парится и содержит одинаковою версию всех модулей и наращивает их вместе. Так проще пользователю, сложновато догадаться что module-data-0.2 и module-web-0.7 - это комбинация хорошо работающая вместе

Но обычно никто не парится и содержит одинаковою версию всех модулей и наращивает их вместе.

Не всегда это срабатывает. Если несколько независимых команд, то только диапазоны помогают. Дабы не было «узкого горлышка бутылки» в виде версий в DependencyManagement.

Так проще пользователю, сложновато догадаться что module-data-0.2 и module-web-0.7 - это комбинация хорошо работающая вместе

достаточно немного исправить утверждение: «module-data-0.* и module-web-0.* - это комбинация хорошо работающая вместе»
и сразу разные команды разработчиков перестают толкаться локтями. :)

«module-data-0.* и module-web-0.* - это комбинация хорошо работающая вместе»

Не уверен, учитывая что почти любой код плохо работает вместе, то скачки по минорным версиям нужно тестировать отдельно

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

Скачки по минорным версиям сглаживаются контрактами между артефактами. Например, добавили в artifact1 некую публичную фичу, описали её поведение - и кровь из носа, но в пределах диапазона версий эта фича должна оставаться неизменяемой. Можно её багфиксить, можно рефакторить, но ни в коем случае не менять существующее (дефолтное) поведение. Для нового поведения заводится новая фича, а не меняется старая (пусть даже новая фича дублирует старую на 99%). Например, переименовывание одного поля в JSON-ответе. Это должно быть новой фичей, Пишется где-нибудь TODO, что в API следующей версии нужно пересмотреть эту и другую похожую фичу и до смены диапазонов всё забывается. Смена диапазона версий - это фактически переход на API следующей версии. А там новый контракт по фичам и по поведению...

По хорошему думаю это надо на CI бы завернуть

Да, думаю это будет правильно. У нас CI сам наращивает и коммитит версию после успешной сборки. Плюс потом ещё оповещает Delivery Integration, но это уже другая песня :)

Вариант с диапазонами версий еще не пробовали, надо будет проверить.

dependencyManagement?

Да, в некоторых проектах зависимости модулей сейчас прописаны именно так.

отдельную скриптовую обвязку

Я одно время примерно так обновлял зависимости на последние версии:

find -name "pom.xml" -exec mvn versions:use-latest-versions -Dincludes=foo.bar:foo.bar.some.group:* -f {} \;