And if a non dev says they won’t move off 1.3? Will it change any committer or PMC minds on actually continuing to do 1.3 releases? If not I think we have to call it for lack of interest and bandwidth.
1.4 is a functional superset of 1.3 and the current stable line anyway. Seems little reason not to upgrade save inertia or risk aversion. > On Dec 2, 2019, at 5:43 PM, Sean Busbey <[email protected]> wrote: > > Anyone who wants branch-1.3 to keep having releases has to be willing > to volunteer to maintain it. If the note in the 1.3.6 release wasn't > sufficient motivation to get them to show up on dev@hbase to do so, I > could put a more explicit mention of it in the EOM message. We'd need > to come up with some phrasing that didn't leave the status of the > release line ambiguous though. > > For reference, these are the last two EOM announcements we did: > > * 2.0.z in Sep 2019: https://s.apache.org/slgsa > * 1.2.z in Jun 2019: https://s.apache.org/g8lnu > > 2.0 and 1.3 were never a release line with the "stable" marker on it. > 1.2 was the stable release line prior to 1.4. > >> On Mon, Dec 2, 2019 at 1:58 PM Misty Linville <[email protected]> wrote: >> >> Whether any non-dev users are unable to move off 1.3, I suppose. >> >>> On Mon, Dec 2, 2019 at 11:04 AM Sean Busbey <[email protected]> wrote: >>> >>> On what, specifically? >>> >>>> On Mon, Dec 2, 2019, 11:24 Misty Linville <[email protected]> wrote: >>> >>>> Should the user list be allowed to weigh in? >>>> >>>> On Mon, Dec 2, 2019 at 7:33 AM Andrew Purtell <[email protected]> >>>> wrote: >>>> >>>>> I think there is a consensus on moving the stable pointer, based on >>>>> earlier discussion. What I would suggest is a separate thread to >>> propose >>>>> it, and if nobody objects, do it. >>>>> >>>>>> On Dec 2, 2019, at 5:14 AM, 张铎(Duo Zhang) <[email protected]> >>>> wrote: >>>>>> >>>>>> +1. >>>>>> >>>>>> And I think it is time to move the stable pointer to 2.2.x? I know >>> that >>>>>> 2.2.x still has some bugs, especially on the procedure store, but >>>> anyway, >>>>>> we have HBCK2 to fix them. >>>>>> >>>>>> And for the current stable release line, 1.4.x, the assignment >>> manager >>>>> also >>>>>> has bugs, as it is the reason why we introduced AMv2. >>>>>> >>>>>> So I do not think bug free is the 'must have' for a stable release >>>> line. >>>>>> >>>>>> Jan Hentschel <[email protected]> 于2019年12月2日周一 >>>> 下午4:57写道： >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> From: Sakthi <[email protected]> >>>>>>> Reply-To: "[email protected]" <[email protected]> >>>>>>> Date: Monday, December 2, 2019 at 3:32 AM >>>>>>> To: "[email protected]" <[email protected]> >>>>>>> Subject: Re: [DISCUSS] EOM branch-1.3 >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Sun, Dec 1, 2019 at 6:28 PM Andrew Purtell < >>>> [email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> wrote: >>>>>>> >>>>>>> +1 for EOL of 1.3. >>>>>>> >>>>>>> Onward to 1.6! >>>>>>> >>>>>>> >>>>>>>> On Dec 1, 2019, at 5:38 PM, Sean Busbey <[email protected]<mailto: >>>>>>> [email protected]>> wrote: >>>>>>>> >>>>>>>> Hi folks! >>>>>>>> >>>>>>>> It's been about a month since the last 1.3.z release came out. >>> We've >>>>>>>> been talking about EOM for branch-1.3 for about a year. Most >>>> recently, >>>>>>>> we had a growing consensus[1] to EOM after getting the 1.3.6 >>> release >>>>>>>> out with the fixes for Jackson in HBASE-22728 out. >>>>>>>> >>>>>>>> Looking at the things that have since landed in branch-1.3 and >>>> nothing >>>>>>>> looks critical (these are all Major or Minor)[2]: >>>>>>>> >>>>>>>> - HBASE-23149 hbase shouldPerformMajorCompaction logic is not >>> correct >>>>>>>> - HBASE-23185 High cpu usage because getTable()#put() gets config >>>>>>>> value every time >>>>>>>> - HBASE-23261 Region stuck in transition while splitting >>>>>>>> - HBASE-18439 Subclasses of o.a.h.h.chaos.actions.Action all use >>> the >>>>>>>> same logger >>>>>>>> - HBASE-23207 Log a region open journal >>>>>>>> - HBASE-23250 Log message about CleanerChore delegate >>> initialization >>>>>>>> should be at INFO >>>>>>>> >>>>>>>> Someone on 1.3.6 can get all these same things fixed by upgrading >>> to >>>>>>>> our current stable release. >>>>>>>> >>>>>>>> Releases on 1.3.z started in 2017. The branch has only averaged ~2 >>>>>>>> maintenance releases a year; I think reflecting a lack of community >>>>>>>> interest in maintaining the branch. For comparison 1.4 started >>> about >>>> a >>>>>>>> year later and has already had twice as many maintenance releases. >>>>>>>> >>>>>>>> - 1.3.0: 2017-01-16 >>>>>>>> - 1.3.1: 2017-04-21 >>>>>>>> - 1.3.2: 2018-03-07 >>>>>>>> - 1.3.2.1: 2018-06-13 >>>>>>>> - 1.3.3: 2018-12-21 >>>>>>>> - 1.3.5: 2019-06-10 >>>>>>>> - 1.3.6: 2019-10-20 >>>>>>>> >>>>>>>> Any objections to shutting branch-1.3 down? If folks show up down >>> the >>>>>>>> road and want to do the work of maintaining it for some reason, we >>>> can >>>>>>>> always spin it up again. >>>>>>>> >>>>>>>> [1]: >>>>>>>> >>>>>>>> There's more background if you search farther back, but most >>>> recently: >>>>>>>> >>>>>>>> * "Considering immediate EOL of branch-1.3 and branch-1.4" >>>>>>>> https://s.apache.org/f32d0 >>>>>>>> * https://issues.apache.org/jira/browse/HBASE-22728 >>>>>>>> * https://issues.apache.org/jira/browse/HBASE-22835 >>>>>>>> * ANNOUNCE for 1.3.6 included a warning >>>>>>>> "This is ought to be the last release in the 1.3 line unless >>>> something >>>>>>>> critical comes up within in the next month or so." >>>>>>>> >>>>>>>> [2]: >>>>>>>> >>>>>>>> https://issues.apache.org/jira/projects/HBASE/versions/12346250 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>>
