> > My interpretation is that we would cut support/1.13 from develop on the > next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x > patch releases directly from this branch. Otherwise it becomes a two-step > process if all patches have to be cherry-picked from develop -> support/x.y > -> release/x.y.z. Assuming patch-worthy fixes will already be vetted by > the community as critical in order to bring them to support/x.y, it doesn’t > seem like we’d gain anything but unnecessary complexity to require a second > round of sifting. >
Sounds reasonable to me. -Dan On Mon, Mar 2, 2020 at 4:33 PM Owen Nichols <onich...@pivotal.io> wrote: > My interpretation is that we would cut support/1.13 from develop on the > next scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x > patch releases directly from this branch. Otherwise it becomes a two-step > process if all patches have to be cherry-picked from develop -> support/x.y > -> release/x.y.z. Assuming patch-worthy fixes will already be vetted by > the community as critical in order to bring them to support/x.y, it doesn’t > seem like we’d gain anything but unnecessary complexity to require a second > round of sifting. > > support/1.12 will have to be cut from release/1.12.0 as a one-time special > case, but the end result should be indistinguishable. > > > On Mar 2, 2020, at 4:24 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > > +1 to the proposal as written. > > > > The proposal does talk about support branches, but doesn't describe when > > they are created. Is the idea that we create a support/1.X branch as soon > > as we release geode 1.X, and then create release branches off of that as > > needed? > > > > -Dan > >
