I'm confused, isn't the idea of #1 to not have a feature branch at all? In any case, I have a slight preference for #2. I suspect that the majority of changes to trunk will be optimizations, which should be reasonably easy to merge into 0.9. A separate branch also more clearly advertises the "prototype-ness" of 0.9 functionality, discouraging accidental, blind dependence on it. Plus, you've offered to maintain it :)
2c, --John On Fri, Dec 5, 2008 at 4:46 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > If we go with #1 we can selectively merge changesets from the feature > branch back into trunk and leave the bad revisions behind. > > If we do this then I must request that everyone use subversion 1.5 so we > can do this cleanly. > > > > On Dec 5, 2008, at 4:40 PM, John Hjelmstad wrote: > > Won't we have to revert in either case if a proposal is amended or >> rejected? >> >> On Fri, Dec 5, 2008 at 4:35 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: >> >> Hi, >>> >>> We need a place to prototype the 0.9 proposed changes inside of Shindig >>> and >>> insure that the separate proposals are will properly integrate. This >>> could >>> be done one of two ways: >>> >>> 1) Apply proposed changes to trunk. If a proposal is amended or rejected >>> we may have to revert. >>> 2) Apply proposed changes to a feature branch off trunk, while merging in >>> any upstream fixes. >>> >>> >>> If #2 I'll volunteer to keep it in sync with trunk as much as possible. >>> >>> I have some patches burning a hole in my laptop and I'd love to get them >>> integrated and reviewed :) >>> >>> -- >>> Paul Lindner >>> [EMAIL PROTECTED] >>> >>> >>> >>> >>> > Paul Lindner > [EMAIL PROTECTED] > > > >
