Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of jieryn@gmail.com designates
 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C318061356872B4D892533A28BD08819010BAA66@quipsy1>
References: <C318061356872B4D892533A28BD08819010BAA66@quipsy1>
Date: Mon, 22 Jul 2013 14:35:54 -0400
Message-ID: 
 <CAArU9ibVQ0+vCt8b4+Q4we2K09rEP_R_C91JFJZTh-zc3A0SxA@mail.gmail.com>
Subject: Re: mvn release:prepare does not update parent version
From: jieryn <jieryn@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg <karg@quipsy.de> wrote:
> When I do mvn release:prepare, Maven asks whether I want to update all
> SNAPSHOT version referenced in the POM.

I don't think the language says that at all. I ran a quick build and
I'm not seeing where it says it will update every single SNAPSHOT
version referenced in the POM. Can you please paste it?

> I say "yes" and confirm all suggested replacement versions unchanged.
> When Maven is done, I check the POM.xml.
> It is correctly rewritten for all references, but not for the parent
> version.

And it should not. It will rewrite the versions for the artifacts in
its build plan, and the parent is not part of the build plan in this
way. It would be horrifying, frankly, if running a release in a
project would go update the parent project also.

> The parent version still references the *old* SNAPSHOT, while obviously
> it should now name the *next* SNAPSHOT.

I don't think it should obviously do that. Perhaps you actually
intended to run the release from the parent, if that is true, then you
should do it from there. Not from within some submodule.

> Can somebody tell me what I have to do so that mvn release:prepare will
> also make the parent version point tot he *next* SNAPSHOT, as it does it
> correctly with the dependencies and the project's own version?

Run the release from the proper location. Or if the parent really does
not have a submodule of the project you're errantly trying to run the
release from right now, then you should release it (parent) first and
then make the updates in the unlinked child projects to the latest
release number. The m-versions-p is quite adept at automating this
process.

-Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org