1) There is potential for me to check in the release version, start preparing the release and then someone else checks out the release version and starts doing stuff to it, when they should really be waiting until the next SNAPSHOT version has been checked in. I guess I can use locking for that, but it's been a while since I used locking with a SCM (been on CVS, SVN and Bazaar for a while - not used SourceSafe in four years or so).
I personally prefer releasing manually over getting an automation system to do that. IMO, that's just not what CI servers like continuum are made to do. Too many things can go awry in the course of a build and recovering from a release that failed partway through is a pain in the ass. There's always locking, but our current strategy is to branch the code to do releases. We use subversion, which makes branching (and tagging) very cheaply. We currently are releasing about 40 of our 100+ artifacts, and the current strategy denotes a few things: a) the /tags and /branches belong to the build engineer (me). The developers are free to branch and tag in the /userbranches and /usertags paths. b) a number version (major.minor.release). c) release along a branch for customer-facing releases, Thus for component "foo" at version 1.0.0-SNAPSHOT, to release I create a branch called (literally) "foo-1.0.x" that releases all versions following the pattern "1.0.x". I then switch the head of the trunk to "1.1.0-SNAPSHOT" and let everyone continue on their merry path. When we release that version, we'll branch again to a branch called "foo-1.1.x" d) when a minor version gets deprecated, it's just never released again. We don't delete anything, since it's subversion and difficult to really delete from anyway. e) parent poms are never snapshots for the developers. I spent a good deal of time getting them right and I check and recheck changes to them before I make parent pom releases. This is probably only reasonable since my primary job is managing the build. Since I use a property built in the parent pom with elements over-ridden in child poms to build the scm strings for subversion, I generally only have to change a few properties to get my new branch built by continuum. I do that when I branch the code. Updating the poms by hand for the new versions? Well, that's just the price of admission for a non-modular build. I've had some problems with modular builds over the years and I tend to avoid them, but given the amount of time it's taking to do our releases, I'm starting to give them thought again.
2) Kind of related to that - the need for some sort of development freeze during that day. We don't want that.
Release along a branch in subversion solves this, but that initial branching adds significant time. Enough to effectively more than double our total release time.
Should it really be taking me a day to do a release of this scale or am I doing something fundamentally wrong?
Unless we're both on the wrong road, I think you're pretty much following the path. It takes me about 13 hours to do a full soup-to-nuts release of our 40-ish projects for the final assembly. Most of that time is spent checking for incorrect dependencies that the developers have missed. Fortunately, my parent poms for our projects have improved dramatically, so we're no longer releasing parent poms in the course of a normal release. Parents belong exclusively to me so I release them when needed and get the developers to update to the new parents a few days prior to release (hopefully). That gives me a couple of days of instability to make sure I didn't screw up the build by releasing a new parent. Hope some of this helps. Mykel
