Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of jason.dillon@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=hH+RwpYEaveH5rQ/ouATY0xklflTdAcK1dF2prwS7nroxPsa+E0Sy0MUreM8VxmdgBsl5AnlpRDXdeFD1KsTXoHo0Qo3O0TJXtopt6QZNCM0s5wqdb5wkE/VS/dwZmj6xI97XwAX2V3Ia8tKF4ylfEWlbtJuxMGy7Lr/2b5XdZo=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <E1175367-37A9-4FA7-9AA9-2C83E2941316@yahoo.com>
References: <5C354315-5A1B-4ACE-B722-F077674EDD68@hogstrom.org>
 <458BEB4A.50806@gmail.com> <F9F53904-7E94-47D4-A29B-4EDCB4A8E645@iq80.com>
 <E1175367-37A9-4FA7-9AA9-2C83E2941316@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C6EC30A3-317E-4354-A26B-F1152B587823@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: [DISCUSS] Release process change
Date: Fri, 22 Dec 2006 14:14:08 -0800
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

On Dec 22, 2006, at 11:14 AM, David Jencks wrote:
> I thought from looking at the maven dev list that maven now or in a  
> couple days is going to support staging releases.  I'm considerably  
> less than thrilled by the idea of changing what we vote on,  
> especially just when it looks like hope is on the horizon.

I'm not convinced that the recent work from the mvn team to improve  
the release process for mvn projects is going to solve the release  
problem... I do believe that it is a step forward, but there are  
still a few major issues which I don't see being addressed yet.

One of the big problems is certification of binaries, and release  
build iteration.  For example, many shops generally like to produce a  
set of release artifacts, promote them to QA, let QA perform some  
battery of tests and then bless the binaries.

To accomplish this with mvn (today and even tomorrow or whenever the  
new release support plugins are finished) means that a "real" release  
must be made for each iteration to QA, and when QA comes back and  
rejects a release, code must be altered and a new release must be  
made and the cycle continues until one of blessed.  In mvn terms that  
means that version 1.0.0 might get passed to QA, rejected, and then  
1.0.1 is spun and handled to QA, rejected... etc... maybe the  
*actual* release is 1.0.3, instead of 1.0.0 which users are expecting.

IMO, the problem with mvn releases, is that there is so much version  
encoding in each artifact (name, embedded poms and dependency  
configuration) that it is not possible to take a set of binaries and  
promote them from a DEV release, to QA release to a final blessed  
release.  You must in each case rebuild to change versions, and by  
rebuilding some of the certification is essentially lost.  You and I  
might both know that only version number have changed... but it is  
possible that when changing versions to make a release build that  
something else in your environment has changed (say different JDK was  
used), or perhaps the previously downloaded artifact cache was lost,  
and the build must download new dependencies, which could potentially  
be altered, producing output artifacts which are different.

Unfortunately mvn can not even take a previously build set of  
binaries in a projects target directory and simply install or deploy  
them... but in order for it to deploy it must go through and run the  
previous phases and will re-generate jars and other artifacts.  So,  
you can't even really be 100% sure that in a simple local  
environment, that building artifacts, performing some set of test,  
and then deploying will actually deploy the same set of artifacts  
that you tested with.  Unfortunately mvn differs greatly from ant  
projects in that it tends to redo work instead of detecting that no  
changes are needed and skipping steps.  While it will only recompile  
changed sources (for java at least), it will always at the end  
regenerate a jar and install it into the local repo.

So far I do not see the mvn folks making any progress on solving this  
problem... and IMO, this is required if you are going to certify  
binaries.


> I'm definitely in favor of releasing the specs now, but I'd be more  
> comfortable voting on binaries as we have in the past.

Unfortunately, to do this... if there is a problem with one of the  
binaries, they must be rebuilt using the same version numbers, so its  
not easy to tell which artifacts are from which iteration.  Only way  
around this IMO is to use a separate staged deploy directory for each  
iteration... which isn't something that can be easily enforced/ 
automated by mvn itself, so this ends up being a potential problem  
when running a release, to make sure you configure the iteration when  
publishing for certification.

  * * *

I don't think that projects using mvn should really need to use mvn  
to make releases... but unfortunately due to the complexity of  
actually making a release for a mvn 2.x project it is a necessity.   
With all those versions and scm bits to update... users are kinda  
forced to use the release plugin.

And... I don't think that every single artifact which is included  
into a server build should be "released".  For the server, the  
release is the assembly zip/tgz... mvn forces us to release  
*everything* that is used to make those assemblies and IMO is a huge  
mistake.

  * * *

When it comes to building a project, mvn does a pretty good job,  
better job with out snapshots.

Its plugin system is really getting to be solid and functional,  
though some of the bugs are forcing people to implement potentially  
dangerous workarounds.

Actually building artifacts is reasonable, though most plugins tend  
to always redo work, so re-running a build that is already built will  
redo a bunch of stuff, which just slows things down and introduces  
unwanted side-effects.

Site generation is novel, though most mvn sites are basically clover,  
javadocs and xrefs with a bunch of meaningless negative space gluing  
them together.  Most people I've show site docs to are confused by  
what they re looking at and find it hard to find the interesting bits  
(javadocs, clover, xref).  And for actually project docs, I find wiki  
is much better... so unless a project actually intends to customize  
its mvn site for its official website I think the who `mvn site`  
thing is more of a waste.

But when it comes to releasing things built with mvn... well, mvn has  
a long way to come before its anything which I could consider ideal  
(or even close to ideal).

--jason