On Tue, 19 Jun 2012 08:46:49 +0200, Cédric Beust ♔ <[email protected]>
wrote:
On Mon, Jun 18, 2012 at 11:43 PM, Casper Bang <[email protected]>
wrote:
That's a decent explanation, except that it's not called "verify" but
"prepare" and it pollutes /trunk when fails (POM has been modified and
temp
files created) requiring manual cleanup.
Sorry for the late response...
Couldn't agree more. I tried to convince Jason and the whole crew many
times that it's a bad idea but I failed.
I can't count the number of times that my release process failed for some
reason (bad connection, stash needed, etc...) and I found myself forced
to
increment my product version just to please Maven. Very irritating.
... because you don'k know the release plugin. With a bit of configuration
and Git or Mercurial it doesn't pollute *anything*. My standard releases
are totally performed on the local disk in an atomic fashion (both the
pushes to Git/Mercurial and the deployment of artifacts). Only at the end,
when everything went fine, the stuff get published. If there has been an
error, nothing goes out of my computer (and can be thrown away, then a fix
is applied and the release is retried).
With subversion, unfortunately, it's impossible to prevent a commit from
going out immediately, and this happens during the process. But - apart
from the fact that Subversion is an old fashion to do things - mvn
release:rollback resets everything as it were before the release, with a
compensating commit. No version number is lost. Because of a bug, you only
have to manually delete the tag.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.