What happened to the "vision" level that Rahul requested that we stay on?
This happens *every* time we get into discussions about the build or
release process. Instead of focusing on what we can agree upon people
start going into the nitty gritty details saying: I *don't* like this or
that detail. It's *so* unproductive it makes me sick.
I haven't read all the text below, and I refuse to do so, until we can
reach an agreement on a "vision" level.
simon wrote:
On Sat, 2008-03-22 at 18:18 +0100, Dennis Lundberg wrote:
James Carman wrote:
On 3/21/08, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
If I raise my view and just look at the A, B, C and D headings, it
sounds good. But, there shouldn't be two options under B. IMO we should
always use the release plugin. That will give us consistent releases.
Should something be wrong with the release-plugin we'll be consistently
wrong :-) But bugs are meant to be fixed, so that shouldn't be a problem
in the long run.
Another thing to consider is that the release plugin isn't written
specifically for apache commons or the ASF in general, nor should it
be. Maven is designed to be a general-purpose build system for all
projects. We could consider writing our own release plugin which
enforces/supports our release process. It shouldn't be that tough, if
that's what it comes down to. I think the maven release plugin's
philosophy of cutting/deploying releases differs from ours.
Let us first decide what our release philosophy is, and worry about
finding the right tools later.
I personally dislike the maven-release-plugin a lot.
It does a number of tasks that can be done simply by hand.
It does a number of tasks that are just pointless for us.
But the worst part is that it deals with version-control using the
"least-common-denominator" approach, ie treats svn as if it were cvs.
This causes unnecessary commits, and makes handling a failed release
much uglier than it needs to be.
And it's just plain opaque. People should not have to spend time
learning to use a tool that does something that they could have done
just as easily themselves. Particularly as releases are only done
infrequently.
[1] Ok, I admit that when releasing a whole tree of modules it might
save some effort, ie a pom that has a lot of <module> tags pointing at
modules in subdirs. But we don't have that in commons.
Here's the tasks that "release prepare" does:
http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
(a)
check for uncommitted code
Hopefully everyone already does releases from a freshly-checked-out
directory. That should be part of the release document, in which case
this step is pointless.
Otherwise "svn status" does the trick. Ok, you have to remember to do
it.
(b)
maven-release-plugin checks that there are no SNAPSHOT versions in the
pom.
But isn't
grep "SNAPSHOT" pom.xml
simple enough? [1]
(c)
maven-release-plugin creates a tag for you.
Oh yay. Isn't "svn cp" easy enough?
Anyway, I prefer to create an svn cp in a "branches" directory, then do
the release from there, and move it to the tags dir once the release has
worked. With that approach, there is never a window where the tags dir
contains something marked as a release when the release has not yet
happened.
(d)
maven-release-plugin updates the version number in the pom.
Oh yay. Isn't edit/commit enough?
Anyway, what it does is update the version in trunk, then create the
tag, then update the version in trunk again. Ecch. I think this is
because it is trying to be cvs-compatible.
It is nicer to create a branch, update in trunk to (v+1)-SNAPSHOT, and
update in trunk to remove the SNAPSHOT. Clearer to all watching the
commit logs what is happening.
And if a release needs to be "undone", maven-release-plugin then adds a
new commit to trunk to rewind the version number. But with svn, we on't
need to do that. We can just revert the "release preparation branch" we
created, or svn cp a specific version of trunk.
(e)
Update the scm link, from pointing at trunk to pointing at the tag dir.
Actually, I don't think this is very useful. Pointing at the trunk is
probably better, particularly when a release includes source jars
already.
(f)
Run all tests against the modified pom.
Well, if a "release branch" approach is used, then that happens
automatically when the release candidate code is built.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
