phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva" <tdsi...@salesforce.com>
Subject Re: [DISCUSS] stop minor releases for 0.98 and 1.1
Date Wed, 13 Jun 2018 02:35:10 GMT
+1 on reducing the number of branches.

On Tue, Jun 12, 2018 at 2:03 PM, Vincent Poon <vincent.poon.us@gmail.com>
wrote:

> big +1
> Commits have been way too burdensome
>
> On Tue, Jun 12, 2018 at 9:08 AM, Josh Elser <elserj@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 <elserj@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
> >>>>
> >>>>
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message