; > > >>>>> releases. If we can also have alignment in patch releases too,
> that
> > > >> would
> > > >>>>> be great, but can't be mandatory.
> > > >>>>>>>
> > > >>>>>>>> On J
t;
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Please see the red words carefully, I explicitly mentioned that,
> > the
> > >>>>> newer
> > >>>>>>>&g
1.5.0
> >>>>> has,
> >>>>>>>> but 2.1.1 should have all features which 1.5.0 has.
> >>>>>>>>
> >>>>>>>> Sergey Shelukhin
> >>>>> 于2019年1月19日周六
> >>>>>>>> 上午10:23写道：
at we actually cannot guarantee this without a time
>>>>> machine,
>>>>>>>>> because some "newer" versions are already released.
>>>>>>>>>
>>>>>>>>> If we backport to 1.5 now, we cannot d
.2, etc. because they are already released... if the user
> >> upgrades
> >>> from
> >>>>>>> 1.5 to 2.0.1 for example, they will lose the feature no matter
> what.
> >>>>>>> The only way to ensure is to
> >>>>
sure we never release before releasing every
>>> "later"
>>>>>>> dot release (e.g. we cannot release 1.5 before 2.1.3, 2.0.N, etc. so
>>>>>>> there's the latest release for every line).
>>>>>>> - and also for us
e.g. we cannot release 1.5 before 2.1.3, 2.0.N, etc. so
> > >>>> there's the latest release for every line).
> > >>>> - and also for us to make sure that every single dot line actually
> > has a
> > >>>> release - when e.g. 2.0.X line is
> release - when e.g. 2.0.X line is abandoned that may not happen, so
> the
> >>>> latest version of 2.0.X will precede latest 1.Y because 1.Y may still
> be
> >>>> active (like as far as I recall 0.94 was getting dot releases even
> when
> >>>&g
even if the user goes from 1.Y to the latest 2.0.X
>>>> they will lose the feature.
>>>>
>>>> I think this is kind of expected... I agree that it needs to be
>>>> documented. To an extent it already is in JIRA where fixVersion may be
>>>>
think this is kind of expected... I agree that it needs to be
>>> documented. To an extent it already is in JIRA where fixVersion may be
>>> "3.0, 2.2, 1.5", but it makes sense to document explicitly.
>>>
>>> -Original Message-
>>>
o an extent it already is in JIRA where fixVersion may be
>> "3.0, 2.2, 1.5", but it makes sense to document explicitly.
>>
>> -Original Message-
>> From: 张铎(Duo Zhang)
>> Sent: Friday, January 18, 2019 5:50 PM
>> To: HBase Dev List
>> S
hey will lose the feature.
>>
>> I think this is kind of expected... I agree that it needs to be
>> documented. To an extent it already is in JIRA where fixVersion may be
>> "3.0, 2.2, 1.5", but it makes sense to document explicitly.
>>
>> -Original Messag
I think this is kind of expected... I agree that it needs to be
> documented. To an extent it already is in JIRA where fixVersion may be
> "3.0, 2.2, 1.5", but it makes sense to document explicitly.
>
> -Original Message-
> From: 张铎(Duo Zhang)
> Sent: Friday, Janua
s sense to document explicitly.
-Original Message-
From: 张铎(Duo Zhang)
Sent: Friday, January 18, 2019 5:50 PM
To: HBase Dev List
Subject: About how features are integrated to different HBase versions
I think we have a good discussion on HBASE-21034, where a feature is back
ported to
I think we have a good discussion on HBASE-21034, where a feature is back
ported to branch-1, but then folks think that we should not back port them
to branch-2.1 and branch-2.0, as usually we should not add new features to
minor release lines.
I think the reason why we do not want the feature in
15 matches
Mail list logo
