+1 To Jason's comments with Hiram's comments... I think we should do all development of 1.1.x in branches/1.1 (with version 1.1.N-SNAPSHOT). But at the time we code freeze for a release, I think we should svn copy branches/1.1 to branches/1.1.N and finalize the version numbers there (to version 1.1.N) and make any last-minute tweaks there and update branches/1.1 to version number 1.1.(N+1)-SNAPSHOT. When we have a candidate for the release, then we can svn copy branches/1.1.N to tags/1.1.N and build the release from the tag.
Thanks, Aaron On 6/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
Hi Jason, The problem is that it can take weeks to do a geronimo release since stuff like CTS testing is involved. So the release work (putting the finishing touches) needs to be done in a branch so that work can continue on the next release. Perhaps m2 has a way of dealing with those issues along with re-cutting releases and such. But since I have not done a m2 based release yet, I'm not sure what's involved. Could you clarify it a bit for me? On 6/21/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > > Hi Jason, > > > > I agree that we should avoid branching. But I do agree with the 1.1.1 > > branch. It's a dead-end branch in that it's only used to prepare he > > release. Applying last minute fixes and changing version numbers. > > Since it's a dead-end branch, once the release if approved > > moving/deleting it makes sense. > > I would make those changes on the 1.1 branch (or trunk if we were > using that codebase), then release and let Maven make the tag and > then update the versions to the next SNAP. > > When moving to m2 we really need to follow the m2 release system, > else the number of changes to poms is going to get out of control and > will be very error prone. > > --jason > > > -- Regards, Hiram Blog: http://hiramchirino.com
