commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Date Wed, 09 Oct 2013 04:43:15 GMT
On 2013-10-08, Benedikt Ritter wrote:

> you are involved in other projects (like log4j2) how do they do it? Is
> it easier to release log4j2 than it is to release for example [lang]?

Over the past year I've cut releases at the ASF for Commons Compress,
Ant and log4net and outside of the ASF of a small company sponsored QMQP
library at github and XMLUnit at sourceforge.

The QMQP lib was trivial to release because I didn't have to vote,
didn't intend to have a proper distribution outside of MC and the only
site is the  This wouldn't be possible for anything
non-trivial.  Still there was a Nexus between my command line and Maven
central and it's been more than a single step.

All ASF releases and XMLUnit have been similar - it is always a painful
manual process.  Create a tag, build the stuff upload to Nexus (not for
log4net), upload non Maven-distributables, update site.  In XMLUnit I
can skip the votes, but I don't see how to make anything of this a lot

As long as we think we have to distribute things to three places and
vote on all of them, I don't see how to simplify things.  I must admit
I'm not sure we actually have to do that, we can change the site as
often as we want to, so why vote on it?  And we can trust our tooling,
why vote on Nexus staged artifacts if the tarball is fine?  I'm not
talking about releasing to MC directly but rather about not pushing
anything to Nexus before the vote on the tarball has passed.  This could
reduce the release process to tagging and publishing the tarballs before
the vote.

At work I've been cutting releases for stuff built from 15 git repos
every two weeks - at the end of scrum sprints.  We've automated things
so far that it is mostly down to tagging the repositories and the rest
is done by CI.

But there are things the build process doesn't do and that cannot be
automated for good reasons - PGP signing for example.  I wouldn't want
to put a private key on a CI machine, or rather I wouldn't trust a key
that lived on such a machine.

In addition I probably wouldn't trust the artifacts built on a public CI
machine that is open to as many people as our Jenkins either - it would
be a beautiful target for attacks and a great resource for publishing
backdoored releases if we were to rely on CI to build our releases.


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

View raw message