On Tue, Sep 6, 2011 at 10:00 PM, William G. Thompson, Jr. <[email protected]>wrote:
> On Tue, Sep 6, 2011 at 8:50 PM, Marvin Addison <[email protected]> > wrote: > > <snip /> > > > > > > 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. > My thought on this is more along the lines of a feature branch based on community consensus that its a feature worth exploring. For example, updates to session storage API might be a feature branch. My experiments with rewriting CAS in Scala would probably not be :-) (note: I don't actually have any code for CAS in Scala.... yet) I'll try and read over the document and give more useful feedback beyond this one point. > > > > 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 > > -- 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
