commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Tue, 29 Mar 2011 15:08:58 GMT
On 29 March 2011 16:02, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>  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

We need to keep Nexus, but I agree about the release plugin - see below.

>> 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.
>
> AIUI then the deployment to the maven repository is either by dropping
> the artifacts manually in
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using
> Nexus. I think once a component switches to Nexus, then the manual
> process doesn't work.

Yes, that is true.

Also, had the [net] release been using Nexus, it would have required 2
additional manual stages to close and then release the Maven
artifacts.
It is impossible to accidentally release Maven artifacts using Maven
command-line when using a staging manager such as Nexus.

But I agree that using manual processes up to that point is better
than trying to use the Maven release plugin.

> Niall
>
>>  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
>
>

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


Mime
View raw message