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 23:41:41 GMT
On Tue, Mar 29, 2011 at 10:23 PM, sebb <> wrote:
> On 29 March 2011 20:56, Niall Pemberton <> wrote:
>> 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 <>
>>>>>>>> On Tue, Mar 29, 2011 at 10:08 AM, sebb <>
>>>>>>>>> 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 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
>>>>>>>>>>> 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
>>>>>>>>>>> plugin-munging or other half-success management
>>>>>>>>>>> 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 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
>>>>>>>>> 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.
>>>>>>>> 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 is
>>>>>>>> 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 hard
>>>>>>>> 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 do
>>>>>>>> what we mean with no fuss," perhaps we could cajole Brian
Fox into
>>>>>>>> walking one of us (who solemnly vows to document the entire
>>>>>>>> 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
>>>>>>> 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.
>> See
> A while ago on a different project I complained that some binary
> packages were not part of the vote, and I was firmly told that it was
> only source that mattered.

We are required to release source and people often say the binaries
are only a "convenience" or that the "real" release is the source.
While those things are true, the mistake is then to say that anything
other than the source is not the release. It seems like a logical step
but its not.

The PMC is responsible for what this project *distributes* to people
as releases. Just because its a *binary* convenience artefact doesn't
mean that it isn't subject to the ASF's release policies. Take the
scenario, for example, where something was included in a binary
artefact that we didn't have the rights to distribute - that is why
those artefacts need to only be distributed as a release with the
approval of the PMC.

> When I re-read the documentation on the ASF site at the time, it did
> appear that such an interpretation was possible.

I don't know about that - but whats there now on the "Releases" page
is very clear and IMO makes that interpretation impossible.

> I may be able to find the e-mail thread, but it will take a while.

I don't think there is any point - why would that hold any weight over
what is on the ASF website, very clearly spelled out:


> I'm not saying that I think binary artifacts should not be included in
> release votes - just the opposite - but I was told otherwise.
>> Niall
>>>>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message