commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Tue, 29 Mar 2011 14:50:29 GMT
 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

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


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

View raw message