The part where you say:
>> I retained one exception for the use case where it was a more recent
>> snapshot than the release you selected, and the original choice is restored.
I like (+1).
One use case I see for this is where the dependency is actually a parent pom.
Here's an example:
Consider a set of parent poms:
A (version 2-SNAPSHOT)
B (has parent A:2-SNAPSHOT) (version 2-SNAPSHOT)
C (has parent B:2-SNAPSHOT) (version 2-SNAPSHOT)
Furthermore, presume that
A has <modules><module>B</module></modules> and
B has <modules><module>C</module></modules>
to allow the release plugin to put all the children (recursively) of the thing
being released into the Reactor, and update all of the SNAPSHOT references to
non-SNAPSHOTs when a release is done.
Now consider B changes. To release B (not A - since it doesn't need to be
released):
B and all of its children have their versions updated to just "2", and the next
trunk version set to 3-SNAPSHOT.
B's parent, A, would need to be treated by the Release plugin by this proposed
mechanism, and the intended behavior is I think to have:
(in the release tag) B's parent (A) at version 1 (the last released version of
A), and
(in the next trunk) B's parent (A) at version 2-SNAPSHOT.
This I think is an example of a use-case for the "one exception" mentioned at
the top.
-Marshall Schor
On 9/29/2010 9:50 AM, Brett Porter wrote:
> Hi,
>
> The release plugin has a mode where it can assist you in updating snapshot
> dependencies at release time. A lot of this is better manipulated with the
> versions plugin now, but it seems a useful feature to have at release time if
> you can.
>
> The previous behaviour was a bit weird, though. It would prompt you like this:
>
> Resolve Project Dependency Snapshots.: 'test:MRELEASE-583' set to release?
> (yes/no) yes: :
> What is the next development version? (2.1.3-SNAPSHOT) 2.1.3-SNAPSHOT: :
>
> The first question was redundant - you'd already said you wanted to update
> snapshots and the other option is failure. The second one assumes you'll be
> setting the snapshot to the equivalent release, then automatically to the
> next dev't version. The inflexibility of the first part was pointed out in
> MRELEASE-583 and I applied a change similar to the patch provided.
>
> However, I disagree with the default choice of updating the dependency to
> another snapshot - since this is outside of the reactor it's a better
> practice to pin to the release you just chose. I retained one exception for
> the use case where it was a more recent snapshot than the release you
> selected, and the original choice is restored.
>
> As it's only interactive and the form of the questions change, I don't think
> this will catch anyone by surprise, and encourages better practices.
>
> Does anyone see a downside?
>
> - Brett
>
> --
> Brett Porter
> br...@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
