Release plugin should tag the revision that was built in the prepare phase

[Phillip Hellewell]

So release:prepare does a compile first and then (modifies the pom and)
creates the tag.  That makes sense, but...

the problem is we have some artifacts that take a *long* time (up to an
hour) to build.  During that time developers may check in more changes that
they don't expect to be part of the build (since the build already started).

The problem occurs because the tag gets created from the latest revision at
the end of the compile.  Creating the tag at the end is fine, but it should
create the tag from the revision that was built by release:prepare (e.g.,
with svn you can specify an @REV for the source when doing an svn copy).

Now you're going to say, "that's impossible, because we need to modify the
pom first (version and scm connection)".  I knew you were going to say
that.  But why not modify the pom upfront, before compiling?  Modify it to
what it needs to be for the tag, check it in, and then revert it back and
check that in.  Now there exists a revision in the SCM that is appropriate
to tag from at the end of the release:prepare.

I hope that makes sense.  The only downside here is a few unnecessary pom
file checkins, but we'd rather have that than have builds with unexpected
changes in them.  Not only that but this would avoid the problem that a
breaking change slips in during the middle of release:prepare and you end
up tagging the broken code and you end up with a worthless tag that can
never be deployed.

Phillip

[Thiessen, Todd (Todd)]

You can skip the building of the snapshot by changing the goals in the prepare phase.  This will then jump you right to tag creation, checkout of the tag and building of the tag during the perform phase.

> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Thursday, December 15, 2011 4:58 PM
> To: Maven Users List
> Subject: Release plugin should tag the revision that was built in the
> prepare phase
>
> So release:prepare does a compile first and then (modifies the pom and)
> creates the tag.  That makes sense, but...
>
> the problem is we have some artifacts that take a *long* time (up to an
> hour) to build.  During that time developers may check in more changes
> that
> they don't expect to be part of the build (since the build already
> started).
>
> The problem occurs because the tag gets created from the latest
> revision at
> the end of the compile.  Creating the tag at the end is fine, but it
> should
> create the tag from the revision that was built by release:prepare
> (e.g.,
> with svn you can specify an @REV for the source when doing an svn
> copy).
>
> Now you're going to say, "that's impossible, because we need to modify
> the
> pom first (version and scm connection)".  I knew you were going to say
> that.  But why not modify the pom upfront, before compiling?  Modify it
> to
> what it needs to be for the tag, check it in, and then revert it back
> and
> check that in.  Now there exists a revision in the SCM that is
> appropriate
> to tag from at the end of the release:prepare.
>
> I hope that makes sense.  The only downside here is a few unnecessary
> pom
> file checkins, but we'd rather have that than have builds with
> unexpected
> changes in them.  Not only that but this would avoid the problem that a
> breaking change slips in during the middle of release:prepare and you
> end
> up tagging the broken code and you end up with a worthless tag that can
> never be deployed.
>
> Phillip

[Pino Silvaggio]

Maybe I didn't fully get every steps of your release
but usually you should branch your code and release
from there.

Unless you have total control on your branch/trunk, even then
the best approach should be to branch. We branch on first beta
or code/feature freeze.

On , Phillip Hellewell <[hidden email]> wrote:
> So release:prepare does a compile first and then (modifies the pom and)

> creates the tag. That makes sense, but...



> the problem is we have some artifacts that take a *long* time (up to an

> hour) to build. During that time developers may check in more changes that

> they don't expect to be part of the build (since the build already  
> started).



> The problem occurs because the tag gets created from the latest revision  
> at

> the end of the compile. Creating the tag at the end is fine, but it should

> create the tag from the revision that was built by release:prepare (eg,

> with svn you can specify an @REV for the source when doing an svn copy).



> Now you're going to say, "that's impossible, because we need to modify the

> pom first (version and scm connection)". I knew you were going to say

> that. But why not modify the pom upfront, before compiling? Modify it to

> what it needs to be for the tag, check it in, and then revert it back and

> check that in. Now there exists a revision in the SCM that is appropriate

> to tag from at the end of the release:prepare.



> I hope that makes sense. The only downside here is a few unnecessary pom

> file checkins, but we'd rather have that than have builds with unexpected

> changes in them. Not only that but this would avoid the problem that a

> breaking change slips in during the middle of release:prepare and you end

> up tagging the broken code and you end up with a worthless tag that can

> never be deployed.



> Phillip

[Phillip Hellewell]

On Thu, Dec 15, 2011 at 3:05 PM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> You can skip the building of the snapshot by changing the goals in the prepare phase.  This will then jump you right to tag creation, checkout of the tag and building of the tag during the perform phase.

Thanks Todd; can you give me a hint on how to change the goals that
get run by release:prepare?  Does that mean compiling my own special
version of the release plugin?

I do kinda like the idea of skipping the build of the snapshot.  The
only downside though is when a build is broken we would end up with a
useless tag / unusable version, but maybe we could live with that...

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phillip Hellewell]

On Thu, Dec 15, 2011 at 3:07 PM,  <[hidden email]> wrote:
> Maybe I didn't fully get every steps of your release
> but usually you should branch your code and release
> from there.

Do you mean "branch" or "tag"?

A release is created from a tag, and that is what the release plugin
does for us.

> Unless you have total control on your branch/trunk, even then
> the best approach should be to branch. We branch on first beta
> or code/feature freeze.

Hmm, I think you are talking about something else which has nothing to
do with my problem.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Benson Margulies]

> Do you mean "branch" or "tag"?

A branch.

In a busy environment, the common practice is:

1) use release:branch to make a branch.
2) use release:prepare/perform on the branch

>
> A release is created from a tag, and that is what the release plugin
> does for us.
>
>> Unless you have total control on your branch/trunk, even then
>> the best approach should be to branch. We branch on first beta
>> or code/feature freeze.
>
> Hmm, I think you are talking about something else which has nothing to
> do with my problem.
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jörg Schaible-3]

Hi Phillip,

Phillip Hellewell wrote:

> On Thu, Dec 15, 2011 at 3:05 PM, Thiessen, Todd (Todd)
> <[hidden email]> wrote:
>> You can skip the building of the snapshot by changing the goals in the
>> prepare phase.  This will then jump you right to tag creation, checkout
>> of the tag and building of the tag during the perform phase.
>
> Thanks Todd; can you give me a hint on how to change the goals that
> get run by release:prepare?

See configuration parameters of realase:prepare.

> Does that mean compiling my own special
> version of the release plugin?

No. Just set the parameter up in a pluginMgmt section to inherit it
everywhere.

> I do kinda like the idea of skipping the build of the snapshot.  The
> only downside though is when a build is broken we would end up with a
> useless tag / unusable version, but maybe we could live with that...
>
> Phillip

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Olivier Lamy]

2011/12/15 Phillip Hellewell <[hidden email]>:

> So release:prepare does a compile first and then (modifies the pom and)
> creates the tag.  That makes sense, but...
>
> the problem is we have some artifacts that take a *long* time (up to an
> hour) to build.  During that time developers may check in more changes that
> they don't expect to be part of the build (since the build already started).
>
> The problem occurs because the tag gets created from the latest revision at
> the end of the compile.  Creating the tag at the end is fine, but it should
> create the tag from the revision that was built by release:prepare (e.g.,
> with svn you can specify an @REV for the source when doing an svn copy).

As you use svn, a possible solution is to use remoteTagging=false
(http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#remoteTagging)

which do svn cp . http://blbl/tags/

>
> Now you're going to say, "that's impossible, because we need to modify the
> pom first (version and scm connection)".  I knew you were going to say
> that.  But why not modify the pom upfront, before compiling?  Modify it to
> what it needs to be for the tag, check it in, and then revert it back and
> check that in.  Now there exists a revision in the SCM that is appropriate
> to tag from at the end of the release:prepare.
>
> I hope that makes sense.  The only downside here is a few unnecessary pom
> file checkins, but we'd rather have that than have builds with unexpected
> changes in them.  Not only that but this would avoid the problem that a
> breaking change slips in during the middle of release:prepare and you end
> up tagging the broken code and you end up with a worthless tag that can
> never be deployed.
>
> Phillip

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Thiessen, Todd (Todd)]

http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html

If you look at the preperationGoal option of the prepare goal, you will see the default is clean verify.  If you change with to simple be clean, the prepare phase won't actually try and build the snapshot.

IMHO, your second concern isn't very severe if you have continuous integration in place. If you do, you will always know when your snapsnot is sane making the building of the snapshot during the prepare phase virtually useless.  You of course don't want to release if your CI shows the build to be broken.

> -----Original Message-----
> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Thursday, December 15, 2011 6:48 PM
> To: Maven Users List
> Subject: Re: Release plugin should tag the revision that was built in
> the prepare phase
>
> On Thu, Dec 15, 2011 at 3:05 PM, Thiessen, Todd (Todd)
> <[hidden email]> wrote:
> > You can skip the building of the snapshot by changing the goals in
> the prepare phase.  This will then jump you right to tag creation,
> checkout of the tag and building of the tag during the perform phase.
>
> Thanks Todd; can you give me a hint on how to change the goals that
> get run by release:prepare?  Does that mean compiling my own special
> version of the release plugin?
>
> I do kinda like the idea of skipping the build of the snapshot.  The
> only downside though is when a build is broken we would end up with a
> useless tag / unusable version, but maybe we could live with that...
>
> Phillip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

[Phillip Hellewell]

On Thu, Dec 15, 2011 at 7:16 PM, Benson Margulies <[hidden email]> wrote:
>> Do you mean "branch" or "tag"?
>
> A branch.
>
> In a busy environment, the common practice is:
>
> 1) use release:branch to make a branch.
> 2) use release:prepare/perform on the branch

Ok, I get it now.  So then do you also delete the temp branch afterwards?

Assuming we delete the temp branch after to reduce clutter, the only
real downside I can think of is that when looking at a tag to try and
track down where it came from, you have to go through two steps (of
looking at the "Copied from") instead of one.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phillip Hellewell]

On Fri, Dec 16, 2011 at 12:44 AM, Jörg Schaible
<[hidden email]> wrote:
> Phillip Hellewell wrote:
>> Thanks Todd; can you give me a hint on how to change the goals that
>> get run by release:prepare?
>
> See configuration parameters of realase:prepare.

Ah yes, here it is: "preparationGoals".  Thanks.  I don't know why I
didn't notice that.

>> Does that mean compiling my own special
>> version of the release plugin?
>
> No. Just set the parameter up in a pluginMgmt section to inherit it
> everywhere.

Cool, to change the default in a global way.

Right now we are using a "cheat" to avoid building twice.  After the
release:prepare we do an svn switch to the tag and a mvn deploy,
rather than run release:perform.  But if we were to take the approach
of just not building during the release:prepare phase, we wouldn't
have to do that cheat anymore.

So the only downside I can see to this approach is that when a build
does fail, you end up with a useless tag / version.

Thanks,
Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phillip Hellewell]

On Fri, Dec 16, 2011 at 4:51 AM, Olivier Lamy <[hidden email]> wrote:
>
> As you use svn, a possible solution is to use remoteTagging=false
> (http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#remoteTagging)
>
> which do svn cp . http://blbl/tags/

Thanks for the tip, but I don't think that has anything to do with my
issue.  That sounds like a workaround for a bug in older SVN clients
that causes tagging to fail.

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phillip Hellewell]

On Fri, Dec 16, 2011 at 6:24 AM, Thiessen, Todd (Todd)
<[hidden email]> wrote:
> http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
>
> If you look at the preperationGoal option of the prepare goal, you will see the default is clean verify.  If you change with to simple be clean, the prepare phase won't actually try and build the snapshot.

Yep, I see it now...

> IMHO, your second concern isn't very severe if you have continuous integration in place. If you do, you will always know when your snapsnot is sane making the building of the snapshot during the prepare phase virtually useless.  You of course don't want to release if your CI shows the build to be broken.

Hmm, yeah we do have CI runs going from Jenkins, so I think you're
right.  As long as we don't launch a release build when the last
continuation build failed, then the chance of it failing is very small
(although there is a tiny race condition there where someone could
slip in a breaking change).

Thanks everyone for all your help, and I like all the solutions
presented, but what does everyone think of my idea?  Would it not be a
cool idea to change the release plugin, or at least provide an option,
for it to behave by doing an upfront change of the pom file, so that
when it reaches the tag stage it tags from that revision instead of
having to change the pom file at the end and tag there?

Phillip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]