commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Tue, 29 Mar 2011 19:56:37 GMT
On Tue, Mar 29, 2011 at 8:08 PM, sebb <> wrote:
> On 29 March 2011 18:33, Niall Pemberton <> wrote:
>> On Tue, Mar 29, 2011 at 5:18 PM, sebb <> wrote:
>>> On 29 March 2011 16:52, Phil Steitz <> wrote:
>>>> On 3/29/11 8:33 AM, sebb wrote:
>>>>> On 29 March 2011 16:20, Matt Benson <> wrote:
>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <> wrote:
>>>>>>> On 29 March 2011 16:02, Niall Pemberton <>
>>>>>>>> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <>
>>>>>>>>>  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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
OR by using
>>>>>>>> Nexus. I think once a component switches to Nexus, then the
>>>>>>>> process doesn't work.
>>>>>>> Yes, that is true.
>>>>>>> Also, had the [net] release been using Nexus, it would have required
>>>>>>> additional manual stages to close and then release the Maven
>>>>>>> artifacts.
>>>>>>> It is impossible to accidentally release Maven artifacts using
>>>>>>> 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.
>>>>>> My assumption is that the Nexus stuff is supposed to work and make
>>>>>> life easier.  If it doesn't, I suppose we shouldn't use it.  Is
it a
>>>>>> training issue, such that none of us simply knows exactly what it
>>>>>> we ought to expect the process to do, and how it will do it?  This
>>>>>> type of thing is my chief complaint about Maven in general:  it's
>>>>>> to understand what's going on once you get a level or two of parent
>>>>>> POMs in there.  If it's just a matter of "we haven't discovered
>>>>>> precise incantations that make the release plugin + Nexus instance
>>>>>> what we mean with no fuss," perhaps we could cajole Brian Fox into
>>>>>> walking one of us (who solemnly vows to document the entire experience
>>>>>> in full detail) through the entire lifecycle.
>>>>> Nexus is effectively a proxy, and has little bearing on how Maven
>>>>> deploy or release work.
>>>>> The artifacts end up in Nexus rather than in a directory that is
>>>>> auto-synched to Maven Central.
>>>>> This makes it easy to review the actual artifacts that will be
>>>>> deployed, as well as ensuring that artifacts cannot be accidentally
>>>>> deployed.
>>> Sorry, I was referring to the Maven artifacts, which is what went
>>> wrong with Net.
>>>> 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.
>>> AIUI the ASF release is the *source*, which is normally also released to Maven.
>> IMO I don't quite agree with what either you or Phil said. The release
>> is whatever artefacts that we put out there for users to download. ASF
>> requires that we do a source release and anything else is a
>> convenience - but those other things are part of the release.
> Yes, I agree they are part of what we in Commons consider a release,
> but AIUI that is not the strict ASF position.

No, thats what the ASF considers

> My point was that it was not only the dist/ artifacts that matter.

No, all parts matter.



>>> We don't have to use Nexus for non-Maven artifacts.
>>> IIRC, previously there was little or no visibility of what Maven
>>> artifacts would be released, and they were not always voted on.
>> Rubbish. You make it sound like we only started checking maven
>> artifacts since Nexus.
> That was not my intention.
> I thought I had seen several votes where the Maven artifacts that were
> eventually released were not the exact ones voted on, because the
> release process that was used forced the RM to rebuild the jars in
> order to deploy them.
> But maybe I'm thinking of a different project.
> ==
> Nexus makes it easier to release Maven artifacts, as there is no need
> to mess with the maven-metadata.xml file [1]
> [1]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message