True. I do like the nicely documented method that we can point at. :-) Anyone else have an opinion on this? I could go either way. I just want a documented method that we follow.
Aaron On Monday, July 14, 2014, Chris Rohr <[email protected]> wrote: > The other approach would be to work off of master and branch each release > then you could update the RC's easier. > > On Monday, July 14, 2014, Aaron McCurry <[email protected] <javascript:;>> > wrote: > > > On Mon, Jul 14, 2014 at 2:49 PM, Chris Rohr <[email protected] > <javascript:;> > > <javascript:;>> wrote: > > > > > Hi all, > > > > > > I know this was brought up a few days ago, but now that 0.2.3 is out > for > > a > > > vote, I think it should be brought up again. How is the branching > going > > to > > > work going forward? > > > > > > Most repos I have seen have master be the latest stable code and new > > > branches are used for development of the next versions and then merged > in > > > to master upon release. > > > > > > > I think based on our previous discussion the answer is yes. > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-blur-dev/201406.mbox/%3ccab6ttr24vbg2qbxxwzd9q+xb4bbgkor7w3h4wfsm8jm6dxc...@mail.gmail.com%3E > > > > I think that we should move forward with Andrew's suggestion: > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > If no one has any issues I will go ahead and migrate the apache-blur-0.2 > to > > become master based on this approach: > > > > > > > http://stackoverflow.com/questions/2763006/change-the-current-branch-to-master-in-git > > > > > > > > > > I just want to make sure, as I have some more changes coming and don't > > want > > > to mess up the current vote. > > > > > > > It's tagged so it won't be the end of the world, but it might make a fix > to > > the current RC a little bit tricky. > > > > Thanks, > > > > Aaron > > > > > > > > > > > > Thanks, > > > Chris > > > > > >
