Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 74.125.83.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=ZfyLZUlNXvtkQfTVXhBYMgGRv7AGeHPomTdSUJgbTfGi4hjv489e/3VDywkIj6DfxL
         PyZd23xe4gl8ZJTvyNt5wKngtLf3N3I2kS8j18lcPDJtbuNUkNWDdQzdpj0Lc+jITq6T
         dDrARLpVv26rMQa5YkJdwTOmJzROUuV43FlD0=
Message-ID: <4D91F1B5.8050206@gmail.com>
Date: Tue, 29 Mar 2011 07:50:29 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Release process  WAS [VOTE] Release Apache Commons Codec 1.5-RC1
References: <AANLkTinrxEGJx-HhjiZ+cuJ8=_ww931PB19nRFHTrHKv@mail.gmail.com>
	<AANLkTimE24vhPqcw9mZUa7jn=EiMk789d50XqhPUe43e@mail.gmail.com>
	<4D915031.7060802@gmail.com>
	<AANLkTi=cSSzCcdq46KV3hrMPWAr+aZUFwKrJd_JAO+rQ@mail.gmail.com>
 <AANLkTinkLADJ+zKsrSjAmGwg9u4H-+FgnrG+u18GqPMh@mail.gmail.com>
In-Reply-To: <AANLkTinkLADJ+zKsrSjAmGwg9u4H-+FgnrG+u18GqPMh@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

 After another nightmare by an RM who has not cut a release in a
while, I think we need to do something.  The documentation on the
Commons web pages describes a process that works.  I suggest that we
standardize on that process, adding some simple automation scripts
that RMs can choose to use or not to use for the manual steps and
stop fussing with Nexus or the maven release plugin.  I cut an RC
last night in 25 minutes (about 15 of which were spent waiting for
the [pool] tests to complete) and will likely spend about that same
amount of time deploying the artifacts to dist/ and what remains of
our simple, file-and-directory-based replication infrastructure to
get maven artifacts pushed to the maven repos.  I do use a simple
shell script to manage invoking the maven commands and copying files
around to reduce the required time from, say an hour, to 25
minutes.  The script is in svn.

I prefer the "manual" approach for the following reasons:

1.  I know what it does.  Exactly, every time.  I know that exactly
the binaries that we vote on get deployed to dist/ and exactly the
committed tag is used to build everything.  The process includes
local generation of artifacts that I can inspect and test locally
and verify sigs.  I know at each step exactly what is being pushed
where.

2.  I know that it works.  Every time.  No pom-tweaking,
plugin-munging or other half-success management required.

3.  It has no commercial / proprietary dependencies.  The scripts
are optional and are in any case, ASF-licensed, committed to svn.

I know others have different opinions on this.  It could be we need
to support both ways of cutting releases.  I would ask, however,
that those arguing for the "automagical" approach take a hard look
at how many volunteer hours are being spent trying to get
maven/nexus to be a release manager and how comparatively little
time those of us who take the "manual" approach spend getting our
releases built and deployed.  While I certainly can't claim to
produce perfect artifacts (much less code :), I will also point out
that the only major release quality problem that we have had
recently was the inadvertent release of a [net] version while
fiddling with the release plugin.  I don't at all buy the argument
that the manual approach is "error-prone" as it allows more and
better opportunities for inspection by the RM and community at each
stage.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org