Я полагаю, что между этими ветвями должны существовать взаимосвязи, которые должны решить проблему номеров версий.
Высвобождение
Я предполагаю, что вы могли бы сделать что-то вроде слияния готового кода из ветви dev в ветку release, а затем выполнить релиз Maven (через Jenkins или вручную). Это автоматически сворачивает номера версий до следующей сборки. Таким образом, вы объединяете код 1.4.7-SNAPSHOT с этой веткой, выполняете выпуск и сокращаете версию 1.4.7, и Maven автоматически переводит вашу рабочую копию в 1.4.8-SNAPSHOT.
Обновление базовой линии (необязательно)
Если вы еще не используете свой ствол (или базовую ветвь и т. Д.) В качестве места для своих выпусков, вам следует обновить ствол, как только вы завершите выпуск. Это означает, что номера ваших версий также обновляются. Этот шаг может быть спорным, если вы просто считаете ветку релиза базовой.
Повышение от базовой линии до ветки разработчика
Важно, чтобы ваша ветка разработки была в курсе актуального производственного кода. Вам необходимо объединить код от базовой линии (или ветки релиза, в зависимости от реализации) до вашей ветки разработки. Это важно в вашем случае, потому что это означает, что изменения pom, которые произошли во время процесса выпуска, который изменил версию на 1.4.8-SNAPSHOT, перенесены в эту ветку.
Основываясь на чтении, которое я сделал (а также на процессах в моей организации), это кажется довольно стандартным и эффективным использованием выпусков и снимков Maven, и вместо того, чтобы поддерживать полностью отключенные номера версий в разных ветвях, легко сказать что любая сборка 1.4.7-SNAPSHOT на самом деле была непосредственным предшественником релиза 1.4.7. Они связаны. Я бы сказал, что если вы не объединяетесь между этими ветвями, вы ошибаетесь как в версиях SCM, так и в Maven, и вы подвергаете себя риску разработки против кода, который не соответствует продукту. повторно вводит ошибки в производство и т. д.