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 <[email protected]> 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
