On Tue, Sep 6, 2011 at 8:50 PM, Marvin Addison <[email protected]> wrote: >> I'd like us to consider this model: >> http://nvie.com/posts/a-successful-git-branching-model/ > > This model is too different for no discernible value. I believe the > core idea in this model is described in the following statement: > > "We consider origin/master to be the main branch where the source code > of HEAD always reflects a production-ready state." > > It's common practice for master to reflect _active_ development, and > this corresponds closely to our current practice with active > development happening in svn trunk. Tags serve the role of obtaining > a pointer to a production-ready release, so the proposed model > effectively marginalizes the master branch in favor of another one > called "develop" where active development happens. So it seems to > deviate for no discernible value. Even the diagrams show that master > is effectively inactive except for merge points that are subsequently > tagged. Just develop in master and tag when ready!
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. The release branch would also facilitate cutting and managing release candidates while develop could continue to evolve. > > I personally do not like the idea of feature branches unless it > represents a substantial feature. Provided we agree to the guideline > of "substantial", I would support feature branches. I'll just throw > out a naming convention since consistency is helpful: > > cas-X-feature, where X is a brief feature name or Jira number with > full description Agreed. I wouldn't expect a feature branch for simple changes. I think we'd agree that LPPE is a good example of a feature branch. I suspect OAuth support would be another example. That being said, git makes branching cheap and routine, so our notion of "substantial" may likely change over time. > I think we need to condense the idea of "production" and "hotfix" > branches in this model into our current concept of "maintenance" > branches since we realistically don't have resources to provide > patches to every release. We could potentially backport security > fixes and such to old minor releases, but honestly those are the > exception rather than the rule. We just don't have resources to focus > on anything much more than the tip of master. This seems fairly > standard practice for open source projects -- so much so that "just > upgrade" is a reflexive prescription for bug fixes. There's nothing implicit in the model that dictates patches for every release. We would choose when to cut a hotfix or release branch and for what versions. They can come and go as needed. The only truly long lived branches in the model are develop and master. However, in order to support patching older versions of the software we'd also need "master" branches for those (what we've been calling maintenance branches in svn). 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 about what the approach will be and document it before the move to github. 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
