I agree. Let's tag releases and branch off of tags when needed. We will need to document this on our wiki so we have something to point at. I will take a stab at it ans ask for feedback.
Aaron On Wednesday, July 16, 2014, Chris Rohr <[email protected]> wrote: > This is great! I've been thinking about this more and my opinion would be > that you keep master the stable and create wip branches for future > versions. When those are done then you can merge into master. This approach > would also let you have a patch release and a major/minor release at the > same time all branched off of master initially. > > What do you think? > > Chris > > On Wednesday, July 16, 2014, Aaron McCurry <[email protected] > <javascript:;>> wrote: > > > I have merged apache-blur-0.2 into master and forced apache-blur-0.2 > branch > > to become the new master. > > > > Now the next question is do we follow this paradigm: > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > Or do we simply branch from master when we release? And do development > on > > master? We need to make a decision before we move forward with new > feature > > development. > > > > Thanks! > > > > Aaron > > >
