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 Readme.md. 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 easier. 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. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
