That is something that could be useful, but if I am not wrong, we
haven't needed that yet.
I fear we actually need and use that every time we make a release,
because of the way the projects are split across different repos and
Maven "trees" :-(
The problem we had for 1.6.2-incubating was as follows: at the start
of a release, we first do the main jclouds repo, which results in a
jclouds project POM version of X.Y.Z (no SNAPSHOT).
The next release would be e.g. for jclouds-labs. If jclouds-labs
inherits its version straight from jclouds-project, we have to leave
jclouds-project at X.Y.Z-SNAPSHOT, because otherwise jclouds-labs is
no longer a snapshot version and so can't be released [1].
But we obviously want the released version of jclouds-labs to inherit
from the *released* version of jclouds-project, so we need to set the
jclouds-project dependency to X.Y.Z and keep the version of
jclouds-labs at X.Y.Z-SNAPSHOT *ar the same time*.
Then, if we run the release for jclouds-labs and it still has
dependencies on snapshot core deps (which it will if they use
${project.version}, which is still a snapshot version), the release
plugin prompts you 1,000,001 times for the release version you want to
use, which makes the release process really painful - at least, it was
for 1.6.2-incubating.
Setting the version of the parent POM and all the core deps to the
release version in one commit seems much easier. If we can find a way
to do that without a separate variable for the core dep version, all
the better.
Of course, if we find a way to get the Maven release plugin to "play
nice" and handle all the version updates of deps outside the current
reactor during the release, that would be ideal.
ap
[1] I don't know if the Maven release plugin can prompt you to update
the *parent* POM version as it does for snapshot dependencies - we
should check this!
