Branch 2 doesn't have a release yet never mind enough production experience for 
anyone other than bleeding edge to consider it. Some of us are rebasing 
production on 1.x and once there intend for mid to long term stable operations. 
So I think it is very likely we as a project will be maintaining branch-1 for a 
long time. Perhaps as long as 3 years. (The lifetime of 0.98). Maybe it ends 
with 1.4 but that's probably unlikely. 

> On Aug 8, 2017, at 8:45 PM, Phil Yang <ud1...@gmail.com> wrote:
> 
> Another option is no 1.5/branch-1 any more. What new features we are going
> to have in HBase 1.5 (if it will be released)? Backporting from branch-2 to
> branch-1 is not easy, so maybe we will not have any big feature in branch-1
> after releasing 1.4. And if we release 1.5 after releasing 2.0, it may
> confuse users. So IMO we can focus on branch-2 for new features.
> 
> I think it will be good if we have fixed logic for EOL branches, for
> example(just an example, can discuss):
> 1:Release a final version and EOL 1.x after we think 1.x+1 is stable.
> 2:Cut off new 1.x+2 branch after 1.x+1 is stable, don't cut too early.
> 
> Then we will not need discussing each time for each branch EOL and we will
> have a fixed number of maintaining branches.
> 
> Thanks,
> Phil
> 
> 
> 2017-08-09 1:44 GMT+08:00 Andrew Purtell <apurt...@apache.org>:
> 
>> Well you are not wrong that branching was premature, it turns out. But I'll
>> roll with it...
>> 
>> 
>> On Tue, Aug 8, 2017 at 10:43 AM, Zach York <zyork.contribut...@gmail.com>
>> wrote:
>> 
>>>> I made branch-1.4 a few weeks ago only.
>>> 
>>> Whoops, sorry for that! For some reason I thought I had seen it months
>> ago.
>>> 
>>> On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell <apurt...@apache.org>
>>> wrote:
>>> 
>>>> +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are candidates. I
>>> think
>>>> 1.1 has the edge because it lacks locking changes introduced into 1.2,
>>> just
>>>> like 1.2 lacks locking changes introduced in 1.3 - the latter of which
>>> has
>>>> had far reaching consequences, and the former not an insignificant
>> change
>>>> either.
>>>> 
>>>> 
>>>> 
>>>> On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk <ndimi...@gmail.com>
>>> wrote:
>>>> 
>>>>> On Tue, Aug 8, 2017 at 9:15 AM Mike Drob <md...@apache.org> wrote:
>>>>> 
>>>>>>> The discussion also brought up the notion of an LTS release line.
>>> I'm
>>>>> not
>>>>>>> sure how this jives with the more fequent minors, but would
>> require
>>>>> some
>>>>>>> branch that's so stable that an RM can effectively spin releases
>>>> blind.
>>>>>> 
>>>>>> Seems to me like this branch would necessarily need to be very
>>>>>> backport-light? Only the top of the highest priority issues would
>> be
>>>>>> backportable to it, no?
>>>>> 
>>>>> 
>>>>> The LTS is as 1.1 is today -- bug fixes only. The difference here is
>>> we'd
>>>>> "formally" recognize the LTS designation somehow, perhaps with a
>>> symlink
>>>>> marker as we do for the "stable" designation.
>>>>> 
>>>>> On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk <ndimi...@apache.org>
>>>> wrote:
>>>>>> 
>>>>>>> Last time we DISCUSSed EOL of 1.1 was back in November. At that
>>>> time, a
>>>>>>> litany of issues were raised re: 1.2. Have those concerns been
>>>>> addressed?
>>>>>>> It seems to me that making this one the last release is too
>> abrupt
>>> to
>>>>>> folks
>>>>>>> tracking Apache. Would be better to give some notice.
>>>>>>> 
>>>>>>> Had a nice hallway conversation a couple months back (at
>>> PhoenixCon,
>>>> as
>>>>>> it
>>>>>>> happens; they feel the pain as well) about our branch situation.
>>> I'll
>>>>> let
>>>>>>> the others chime in with more details, but the gist as I recall
>> is
>>>> that
>>>>>> we
>>>>>>> should be doing more frequent minor releases with fewer patch
>>>> releases.
>>>>>>> This pushes stabilization efforts closer to master and also
>> imposes
>>>>> more
>>>>>>> strict stability requirements on big new features before they can
>>> be
>>>>>> merged
>>>>>>> off the feature branch.
>>>>>>> 
>>>>>>> The discussion also brought up the notion of an LTS release line.
>>> I'm
>>>>> not
>>>>>>> sure how this jives with the more fequent minors, but would
>> require
>>>>> some
>>>>>>> branch that's so stable that an RM can effectively spin releases
>>>> blind.
>>>>>>> 
>>>>>>>> On Tue, Aug 8, 2017 at 12:14 AM Stack <st...@duboce.net> wrote:
>>>>>>>> 
>>>>>>>> (This came up during dev meeting in Shenzhen) We are running
>> too
>>>> many
>>>>>>>> branches and/or when applying patches, we do not do a good job
>>>>>>> backporting
>>>>>>>> to all active branches, especially fixes.
>>>>>>>> 
>>>>>>>> We have master, branch-2, branch-1, branch-1.4, branch-1.3,
>>>>> branch-1.2,
>>>>>>> and
>>>>>>>> branch-1.1 active currently. If a dirty bug fix, the applier is
>>>>>>> backporting
>>>>>>>> to 7 branches. It takes a while applying to all especially if
>> the
>>>>>>> backport
>>>>>>>> doesn't go in clean. I suppose the RM could monitor all
>> upstream
>>> of
>>>>>> them
>>>>>>>> and then pull wanted patches back (we could do that too) but
>>> seems
>>>>>> like a
>>>>>>>> burden on an RMer.
>>>>>>>> 
>>>>>>>> We should EOL a few?
>>>>>>>> 
>>>>>>>> Nick is on branch-1.1 release at the moment. Perhaps this could
>>> be
>>>>> the
>>>>>>> last
>>>>>>>> off branch-1.1.
>>>>>>>> 
>>>>>>>> 1.2 hosts our current stable release though 1.3 is out. How
>> about
>>>> we
>>>>>> cut
>>>>>>> a
>>>>>>>> release off 1.3, call it stable, and then EOL 1.2 after another
>>>>> release
>>>>>>> or
>>>>>>>> so?
>>>>>>>> 
>>>>>>>> What you all think?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> S
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Andrew
>>>> 
>>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>>> decrepit hands
>>>>   - A23, Crosstalk
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk
>> 

Reply via email to