On Mon, Jun 21, 2010 at 6:30 PM, kelvin goodson <[email protected]> wrote: > Having gone through the release processs recently, and seeing all the > good improvements ant has been making to make it easier to release in > future, here are some notes on where the pain points were for me, as > input to any further improvements we may like to make. > > most of the pain was just the lenth of time it takes to issue the long > stream of commands, nurse them through their execution, verify their > correct working and iterate over subparts of the process as indicated > by the success or otherwise of any given step. With so many steps > it's also easy to make a slip
Thats hopefully what the new release profile will help fix and most of the steps can be done with a single command. > > With reference to [1] here are some specific issues > > svn:merge is unworkable due to mergeproperties all over the source > hierarchy (not sure if this has now been addresed?) > We discussed this recently and i think the conclusion was that we should remove the properties, i guess now someone just needs to go do it - http://apache.markmail.org/message/uhchnitjfzo7glsg > there's a bug in signing maven artifacts which means some ended up in > the apache repo with bad signatures. There's a suggested fix I think > at [2] > Should be ok now in the release profile. > dependency artifact version checking > I'm not sure what you mean but that one? What needs to be checked? > setting the branch version to <newrelease>-SNAPSHOT is good for > trapping issues, but bad for merging fixes from branch to trunk (can't > just let it a merge run, must police these changes) > Not sure what we could do to help with that. I guess try to do pom.xml changes for things like dependency versions updates before the branch is taken. Also, if we can speed up the release process so doing a release doesn't take weeks then there's less of a window for these type of changes. > upload speed: I wanted to do some things locally, and some things I > wanted to use a remote machine for faster artifact upload. If I recall > correctly the main things I wanted to do locally was artifact signing, > both distros and maven artifacts. Aside from not really wanting my > code signing private key on a remote machine, there were issues > importing a private key. It seemed to be bad form to do this, so much > so that the arguments on gpg to allow it seem to have been withdrawn. > All the required signing is now done with the gpg plugin in the release profile, and all the uploading happens when that is run. Theres a lot to upload so it will still be quite slow but hopefully we'll be able to kick it off with a single command and go away while it runs. > Checking the RAT reports -- now fixed I think. There's probably a > knack to doing this quickly, but I found it a bit of a chore. > Yes RAT runs as part of the build now > Understanding which directories to do maven deploy from > Thats all done in the one release profile now > using the maven staging plugin to copy artifacts (no pain, I just > didnt do it this way as the other way was tried and tested) > I think Nexus will help with this. The staged artifacts will go to Nexus and then they're copied to the live repos with some Nexus command. I'm not totally sure how it all works yet, we just need to try it out, and theres some doc about it at: http://maven.apache.org/developers/release/apache-release.html ...ant
