Some plugins can help here, as already mentioned in this answer and in the comments of this one: the Maven Release Plugin if you want to fully automate the release and/or the Maven Versions Plugin.
With the Maven Release Plugin
Releasing a project with the Maven Release Plugin is done in two steps: prepare
and perform
and here is what the documentation writes about the release:prepare
goal:
Preparing a release goes through the
following release phases:
- Check that there are no uncommitted changes in the sources
- Check that there are no SNAPSHOT dependencies
- Change the version in the POMs from x-SNAPSHOT to a new version (you
will be prompted for the versions to
use)
- Transform the SCM information in the POM to include the final
destination of the tag
- Run the project tests against the modified POMs to confirm everything is
in working order
- Commit the modified POMs
- Tag the code in the SCM with a version name (this will be prompted
for)
- Bump the version in the POMs to a new value y-SNAPSHOT (these values
will also be prompted for)
- Commit the modified POMs
In other words, the Maven Release Plugin is exactly doing what you're asking for.
With the Maven Versions Plugin
If you don't use the Maven Release Plugin, the Maven Versions Plugin can be helpful. In particular, the following goals:
versions:update-parent
updates the parent section of a
project so that it references the
newest available version. For example,
if you use a corporate root POM, this
goal can be helpful if you need to
ensure you are using the latest
version of the corporate root POM.
versions:update-child-modules
updates the parent section of the child modules of a project so the
version matches the version of the
current project. For example, if you
have an aggregator pom that is also
the parent for the projects that it
aggregates and the children and parent
versions get out of sync, this mojo
can help fix the versions of the child
modules. (Note you may need to invoke
Maven with the -N option in order to
run this goal if your project is
broken so badly that it cannot build
because of the version mis-match).
versions:set
can be used to set the project version from the
command line.
versions:commit
removes the pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
versions:revert
restores the pom.xml files from the
pom.xml.versionsBackup files. Forms
one half of the built-in "Poor Man's
SCM".
I mentioned several goals but the "most" interesting is probably versions:update-child-modules
here. It would allow to change the version in the top parent pom and then to automate the update of the child. See Fixing a multi-module build for an example.
Can't help more, you need to experiment yourself now. Good luck!
References