On Wed, Sep 7, 2011 at 10:11 AM, Marvin Addison <[email protected]> wrote: >> The value of having a master and a develop branch is in the way that >> master is only updated via a hotfix or a release branch thus freeing >> up develop for continued evolution without the need for a code freeze >> as is typical with svn/trunk style. > > Merging from the active development branch into a tag is functionally > equivalent, and would be natural to any of us subversion users.
I'm not sure what you mean...merging active dev branch into an svn/tag? To pull this off in git, you'd have to create a branch for the merge, no? Also, how does this avoid the code freeze? > More > to the point, of the following random open source projects I reviewed, > none uses the model you're advocating: > > - http://git.springsource.org/spring-security/spring-security > - https://github.com/grails/grails/branches > - https://github.com/django/django/branches I'm not advocating for the model as much as I'm offering it up for consideration. I see value in the model in the way it provides structure and facilitates collaboration. Since, we making a switch it's good time to consider it. It's obviously not the only model out there. One way or the other I suspect we'll arrive at the goals of the model either by design or ad-hoc. > >> I'd be happy trying this model; it's clear, documented, and ready to >> go. If not this one, I think we need come to some consensus > > My proposal is still up for vote. I'm happy to include > cas-lppe-feature in the branches we'll port, but a single active > development branch, master, is what I've proposed and is both common > and best practice. While I'd like to come to consensus, I'm happy > with majority wins in order to move forward. We should strike a > balance between planning and execution; I'd like to act on this Sunday > night. Since this is essentially procedural, following apache style consensus, majority wins seems to be in order. Adding feature branches and the "Decentralized but centralized" model described here: http://nvie.com/posts/a-successful-git-branching-model/ I'd be a +1. Following the examples you sited, I think the mapping would look more like this: * cas-3_4_x_maintenance -> master (tip of active development/integration/release branch) * cas-3_4_x_maintenance -> 3.4.x (maintenance branch if need for a point or security release) * cas-3_3_x_maintenance -> 3.3.x (maintenance branch if need for a point or security release) * rfe-lppe (feature branch) * rfe-cas4api (big feature branch :) I agree with Scott that a 3.2.x branch is probably unnecessary at this point. We could in fact delay the creation of the maintenance branches altogether (assuming the svn/tags are mapped probably to git/tags) until they are needed. If we're in flight for CAS3.5 on master that would likely spell the end of 3.4.x. releases unless there was a security issue. Bill > > M > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
