On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote: > * Since the trunk is being continuously built by Continuum, > trying to do our release cutting there (including removing > SNAPSHOT from the version numbers) would cause Continuum > to publish a release, with the real version number, before > we had a chance to vote on it. Hence, we need to branch > for the actual release cutting process, and do it there. So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-)
Yep. Two other notes: * Anything that gets integrated into the branch will also likely need to get integrated into the trunk. The other way around is not necessarily true ... it's likely best to minimize big changes on the trunk until the release is basically settled. * During the branch-and-release process, the RM should get final say on whether any new issues get tagged with the ongoing release as "Fixed In Version". After all, he or she is after one thing ... get the release *out* :-).
* I have a desire to push our further development process to a > model where we're doing "new feature" development only on the > trunk, but we maintain active branches for backporting bugfixes > and security patches as needed. [...] > I've been seeing lots of projects get dinged because they mix > bugfixes and feature updates all the time, so you can't get one > without the other -- to say nothing about how it stretches out > your release cycles (just as we're seeing with 1.0.4 :-). Today's > thread on the MyFaces dev list is just one sample of this. I'm definitely in favor of this approach. I've been following the MyFaces discussion. As a MyFaces user I'm stuck in a place where I have to depend on a snapshot simply because our application cannot use any combination of core and tomahawk code I really don't want to get into a situation like that with Shale and it could happen easily. We're like MyFaces in that we have multiple sub-projects that can live independently but have to be able to work together.
Yep.
From a developer perspective, I think setting up a branch whenever > you want > to work on a new feature when it's not the right time to build it > into the > next release will help us remove that instinctive pressure to add > "one more > feature", but also satisfy the itch that I want to get my initial > work out > there shared someplace it can be collaborated on. Yep, I had the first big Tiles refactor on my computer for at least a month before I was able to commit it and that was a sandbox project! I think this would also render moot the decision whether or not to do separate or combined releases. Greg
Craig
