commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [m2][PROPOSAL] Release process
Date Sat, 22 Mar 2008 18:49:30 GMT
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 <> 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:
> (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:
> For additional commands, e-mail:

Dennis Lundberg

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

View raw message