commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1
Date Tue, 29 Mar 2011 21:23:44 GMT
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
>>>>>>>>>> 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 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 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.
>>>>>>> My assumption is that the Nexus stuff is supposed to work and
>>>>>>> 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?
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>> 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.
When I re-read the documentation on the ASF site at the time, it did
appear that such an interpretation was possible.

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

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:

View raw message