If it's read-only you won't be able to make some changes after
release:prepare. Don't you ?
I probably missed something. To make a release:
1 - execute release:perform
2 - check if everything is ok, if not correct the problems.
3 - re-execute release:perform to take the correction
4 - execute release:perform.
On the step 3, you move the tag( using cvs ), or do you create a new one ?
Benoit
Kalle Korhonen wrote:
Move - you mean change? If so, that's completely dependent on your scm. With
svn, one of the easiest ways to accomplish that is with permissions; simply
make it read-only.
Kalle
On 1/28/08, Benoit Decherf <[EMAIL PROTECTED]> wrote:
Ok, thanks, but how do you prevent that nobody will move the tag after
the release:perform is executed ? Is there a way to do that ?
Benoit
Kalle Korhonen wrote:
You can of course run it at once by putting the two commands together if
you
so wish. But normally it's extremely useful to run release:prepare
first,
then examine the tag (like that you really got all of the version
numbers in
the readme, meta-inf right, an installer - if you have one - works and
looks
right, run manual functional tests against it etc.) before you actually
deploy the artifacts with release:perform. If you are not happy with the
tag, you can just decide to abandon the release and do a new one, or if
you
are using svn or some other scm that allows you to modify the tag, you
can
just decide to fix the release notes or another minor detail directly in
the
tag before performing the release.
Kalle
On 1/25/08, Benoit Decherf <[EMAIL PROTECTED]> wrote:
I have a little question about the release process :
Why it is done in 2 steps ?
Why don't we execute the prepare and perform goals at once ?
It's a little strange to make all the works on the scm system but not
deploy the generated artifacts.
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
