commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Thu, 31 Mar 2011 03:06:19 GMT
On 3/30/11 7:07 PM, Ralph Goers wrote:
> I'm seeing a lot of complaining on these threads but no actual proposal.
I started the thread with a proposal, which was to standardize on
the process documented on the web site.  I know you don't like that
process and I am not going to insist that we force everyone to use
the same process.  That is obviously not going to be possible, since
several of us will -1 forcing everyone to use either Nexus or the
maven release plugin.

An improvement of the process on the web site has been suggested,
basically replacing step 3 with an Ant script that pushes maven
artifacts generated by the build automatically.  I will get a
prototype for that working when I cut my next release.

>  If the proposal is to move away from Maven/Nexus for a release for all of commons I'll
vote -1.  OTOH, If some release managers want to do the release some other way I'm not going
to force them to use Maven/Nexus.
> Ralph
> On Mar 30, 2011, at 6:57 PM, sebb wrote:
>> On 31 March 2011 01:38, Phil Steitz <> wrote:
>>> On 3/30/11 4:22 PM, Jochen Wiedmann wrote:
>>>> On Tue, Mar 29, 2011 at 5:52 PM, Phil Steitz <>
>>>>> I disagree with this.  The most important artifacts are the
>>>>> zips/tars that go to dist/.  These *are* the ASF release.  Nexus
>>>>> makes it *harder* IMO to maintain provenance of these artifacts.
>>>> These artifacts are present in Nexus. Pulling them to a temporary
>>>> directory is quite easy with wget.
>>> And then you need to check the hashes and sigs again since you are
>>> now working with downloaded copies of the files that we voted on.
>> Huh?
>> If we create a script to move the files directly from Nexus staging to
>> dist/, surely there's no chance that the cp+rm will somehow mangle the
>> files?
>>> Seems much easier and more correct to me to just scp the files to
>>> p.a.o., let people vote on them and *move* exactly those files to
>>> /dist.
>> Which is much what happens with Nexus now, apart from the dist/ move
>> phase which is not yet automated.
>>>>  At which point I can see no
>>>> difference between your proposed solution and this one. And there's
>>>> nothing to do for all the other files that live in Nexus (and must
>>>> live, because Maven is just too important, whether we like it or not).
>>> Sorry, I don't buy that.  The tars and zips need to "live" in
>>> /dist.  The maven artifacts need to make their way to the maven
>>> mirrors.  Having a "staging" repo where we can inspect the maven
>>> bits before they get pushed out is great (though I think our homes
>>> on p.a.o are fine for this).  Why can't we just push files directly
>>> there using scp or Ant tasks and then "promote" them to the rsynch
>>> repo using a little script including commands like those in step 3
>>> of
>>>>> I also don't see why we *must* rely on proprietary software to
>>>>> manage replication.
>>>> I'm mostly with you on that. I strongly opposed choosing Nexus in
>>>> favour of Archiva for that very reason. But we have Nexus now and I
>>>> wouldn't want to have Commons a swimmer against the rest of the Apache
>>>> tide.
>>> Based on Mark's response, I don't think we are the only ones :)
>>> Phil
>>>> Jochen
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message