> 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! 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 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. 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
