commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [DISCUSS] Creating Project for Release Process Testing...
Date Sun, 13 Oct 2013 23:31:23 GMT
On 11 October 2013 10:23, Emmanuel Bourg <> wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons.  I think it would be immensely
>> helpful for those of us who have been at least part way through the process
>> fairly recently (Emmanuel, Gary, others?) to present your recollections of
>> what was difficult, so that we can have a real list of things to try and
>> address.
> Here is my quick feed back on the release process. For the record I
> prepared the release on Windows by following the 'Using Nexus for
> Commons Maven releases' guide [1]. I also took some bits from the
> 'Releasing Components' guide [2] (unifying these documents would be a
> good start).
> 1. The initial setup is a bit tedious. Generating the GPG key, uploading
> it, configuring the agent, adding the Maven settings. This is not fun
> and sometimes frustrating (I didn't set my ASF password properly in the
> Maven settings and I had to reset it twice. Nexus rejected my uploads
> with a 401 error but I didn't figure my account was locked until I found
> myself unable to commit a change in SVN). Hopefully all of this is
> performed only once.
> 2. The Nexus UI is a bit confusing when you are not used to it. Between
> User Managed Repositories, Nexus Managed Repositories and Staging
> Repositories it wasn't obvious at the first glance to see where the
> action was supposed to take place. A mini howto with annotated
> screenshots would help.
> 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
> is annoying.

Recently, I found that the Maven project RMs don't bother removing these.
So the files are released to Maven Central with the rest.
I assume that the Maven Central administrators don't care about the
extra space needed.

Now ASF source releases must be provided via the ASF mirror system.
There does not seem to be any ruling on whether having additional
copies of the source release elsehere is allowed or not.

I tried asking on Infra whether source releases should only be
published to the ASF mirror system, but got no answer.
Perhaps someone else would like to try?

It would obviously be a lot easier if the Nexus directory did not have
to be purged of these files, as this has to be carefully co-ordinated
with copying the files for the ASF mirror SVN repo.

> I gave up trying to remove the absurd .asc.sha1 and
> .asc.md5 files for JCI, there was too many of them (12 files per
> artifact, 6 artifacts).

That could be automated (I started working on a tool to do this, but
other things intervened).
It's a long-standing Maven bug. The files can be left, but it makes
checking the directory tedious.

> 4. Preparing the release notes is time consuming. I know it can be
> generated from JIRA but I don't find that descriptive enough. Using the
> Maven changes.xml is the best solution, but it has to be maintained
> properly during the development (it wasn't for JCI).

With NET I went through JIRA looking at the "Fix" version to check
that all the issues were in changes.xml.

> 5. I created the tag manually, that was simple enough. I don't trust the
> release plugin. I guess I need some training on a dummy project. Due to
> minor errors spotted afterward I had to recreate the tag twice. So I
> suggest creating the tag only when you have reviewed everything and
> about to send the vote mail.

The release plugin works best if the release vote succeeds; it's messy
if a respin is needed.
There will be SNAPSHOT releases (generated by CI) with the next version in them.
If the release vote fails, these can hang around for a while, causing
possible confusion once trunk moves on as they will become stale.

> 6. 'mvn site:stage-deploy' doesn't work. I got the message
> " = true: Skipping site deployment". This property
> is set in the parent pom! I had to tar the site, upload and install it
> manually on
> 7. I would like a [VOTE] mail generator :)
> 8. Uploading the source and the binary archives on
> implies too many manual steps. This has to be automated (with a Maven
> plugin attached to the deploy phase?).

Automating that was one of the plugins I started working on.
However, it must be done after the vote has succeeded, unless the
files are copied to the dev (staging) repo.
In which case there are then two staging areas to consider for the vote.
It's easier to use Nexus for both.

None of these problems are due to using SVN; most (all?) of these
problems are due to using Maven.

> Emmanuel Bourg
> [1]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message