I'm OK reducing to one single CDH-5.14 branch and dropping 5.11,5.12 and 5.13 support for next minor 4.15.
Same for 0.98 and 1.1 . 1.2 is not really needed for maintaining a cdh branch but could still be relevant - isn't it still the most popular version of HBase in terms of adoption? - . Anyway I agree there are too many parallel branches. On Wed, 13 Jun 2018 at 03:35, Thomas D'Silva <tdsi...@salesforce.com> wrote: > +1 on reducing the number of branches. > > On Tue, Jun 12, 2018 at 2:03 PM, Vincent Poon <vincent.poon...@gmail.com> > wrote: > > > big +1 > > Commits have been way too burdensome > > > > On Tue, Jun 12, 2018 at 9:08 AM, Josh Elser <els...@apache.org> wrote: > > > > > Also +1 > > > > > > Do that after the release? Or before? > > > > > > > > > On 6/12/18 11:55 AM, James Taylor wrote: > > > > > >> Somewhat orthogonal, but we should move master to a new 4.x-HBase-1.4 > > >> branch and make 5.x the master branch. > > >> > > >> On Tue, Jun 12, 2018 at 8:31 AM Josh Elser <els...@apache.org> wrote: > > >> > > >> +1 > > >>> > > >>> I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, > but > > >>> I might be inventing that). I'm also not so sure about the value > behind > > >>> a 1.3 release either (I think Andrew's 1.4 branch is much more > > relevant). > > >>> > > >>> Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, > > we > > >>> can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro > wants > > >>> to support. > > >>> > > >>> On 6/11/18 9:47 PM, James Taylor wrote: > > >>> > > >>>> It feels like we're trying to maintain too many branches. Both HBase > > >>>> 0.98 > > >>>> and 1.1 have been EOLed. To ease the burden on devs, how about we > stop > > >>>> maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can > > >>>> > > >>> always > > >>> > > >>>> step up if need be to do a patch release from the 4.14 branches. > > >>>> > > >>>> Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, > do > > we > > >>>> need the 4.x-HBase-1.2 branch? > > >>>> > > >>>> It'd be good if this was decided prior to the biggish splittable > > system > > >>>> catalog work (PHOENIX-3534) and omid transaction integration > > >>>> > > >>> (PHOENIX-3623). > > >>> > > >>>> > > >>>> Thanks, > > >>>> James > > >>>> > > >>>> > > >>> > > >> > > >
