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
