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
