commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <>
Subject Re: [m2][PROPOSAL] Release process
Date Sat, 22 Mar 2008 17:56:11 GMT

On Sat, 2008-03-22 at 18:18 +0100, Dennis Lundberg wrote:
> James Carman wrote:
> > On 3/21/08, Dennis Lundberg <> 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

[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:

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

maven-release-plugin checks that there are no SNAPSHOT versions in the

But isn't
  grep "SNAPSHOT" pom.xml
simple enough? [1]

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

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.

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

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message