You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "张铎 (Duo Zhang)" <pa...@gmail.com> on 2021/06/30 03:48:44 UTC
Re: Time for 3.0.0 release
Kindly reminder that it is time for our first 3.0.0-alpha-1 now.
张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月31日周一 下午11:37写道：
> 'HBASE-25649 Complete the work on moving all the balancer related classes
> to hbase-balancer module' is done. The rs group related code is still in
> hbase-server, filed HBASE-25953 for tracking the long term work.
>
> Seems no other big progress...
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月22日周六 下午4:05写道：
>
>> FWIW, we should not include a feature which is not ready in the final GA
>> release, so finally we need to purge these feature out. For me, I'm fine
>> with removing feature in alpha releases, but for beta releases, we should
>> not remove features any more.
>>
>> I was also thinking of making release out of master first, for example,
>> the first several alpha releases, and then cut branch-3 for making beta and
>> GA releases.
>> My concern here is that, as we still accept any patches on master, is it
>> possible for us to make it stable enough?
>>
>> And for upgrading, we should at least support rolling upgrading to 3.x
>> from all the active 2.x releases when we cut the first 3.0.0 beta release.
>> Rolling upgrading from all 2.x minor releases line will be a nice to have.
>>
>> Thanks.
>>
>> Sean Busbey <bu...@apache.org> 于2021年5月22日周六 上午10:47写道：
>>
>>> I'm happy to see us moving forward with hbase 3 release.
>>>
>>> If a feature makes it into alpha releases but under evaluation doesn't
>>> look
>>> ready for use, what's the plan? Back things out and put it into a feature
>>> branch?
>>>
>>> What about making releases out of the master branch until we stabilize
>>> the
>>> API by starting beta releases?
>>>
>>> What's our goal for upgrades to 3.0? Any 2.y or some specific minimum?
>>> Rolling upgrade?
>>>
>>>
>>>
>>> On Fri, May 21, 2021, 20:25 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>>>
>>> > Oh, I forgot a big break change, moving to log4j2.
>>> >
>>> > 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月21日周五 下午11:10写道：
>>> >
>>> > > Since favored nodes is an existing feature, an improvement for an
>>> > existing
>>> > > feature can come in at a minor release I think, unless you plan to
>>> > > completely break the compatibility.
>>> > >
>>> > > Mallikarjun <ma...@gmail.com> 于2021年5月21日周五 下午10:11写道：
>>> > >
>>> > >> For multi tenancy with favoured nodes, timeline looks unreasonable
>>> for
>>> > >> 3.0.
>>> > >> Can it be part of later 3.x releases? Or should it wait for 4.0?
>>> > >>
>>> > >> On Fri, May 21, 2021, 7:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > We already have the below big feature/changes for 3.0.0.
>>> > >> >
>>> > >> > Synchronous Replication
>>> > >> > OpenTelemetry Tracing
>>> > >> > Distributed MOB Compaction
>>> > >> > Backup and Restore
>>> > >> > Move RSGroup balancer to core
>>> > >> > Reimplement sync client on async client
>>> > >> > CPEPs on shaded proto
>>> > >> >
>>> > >> > There are also some ongoing works which target 3.0.0.
>>> > >> >
>>> > >> > Splittable meta
>>> > >> > Move balancer code to hbase-balancer
>>> > >> > Compaction offload
>>> > >> > Replication offload
>>> > >> >
>>> > >> > Since now, we do not even have enough new features to cut a minor
>>> > >> release
>>> > >> > for 2.x, I think it is time to cut the 3.x release line now, and I
>>> > >> think we
>>> > >> > already have enough new features for a new major release.
>>> > >> >
>>> > >> > Here I plan to cut a branch-3 at the end of June and make our
>>> first
>>> > >> > 3.0.0-alpha1 release, and finally make the 3.0.0 release by the
>>> end of
>>> > >> > 2021. So if any of the above work can not be done before the end
>>> of
>>> > >> June,
>>> > >> > they will be moved out to 4.0.0.
>>> > >> >
>>> > >> > Thoughts? Thanks.
>>> > >> >
>>> > >>
>>> > >
>>> >
>>>
>>
Re: Time for 3.0.0 release
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Oh, it is this issue.
https://issues.apache.org/jira/browse/HBASE-25520
Let's get this done.
张铎(Duo Zhang) <pa...@gmail.com> 于2021年6月30日周三 下午11:44写道：
> I've moved all the unfinished issues from 3.0.0-alpha-1 to 3.0.0-alpha-2.
>
> And I remember that there is a discussion in the past, to not include
> CHANGES and RELEASENOTES in the release, just use jira to maintain the
> release note, so maybe this time we could make this happen?
>
> Thanks.
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年6月30日周三 上午11:48写道：
>
>> Kindly reminder that it is time for our first 3.0.0-alpha-1 now.
>>
>> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月31日周一 下午11:37写道：
>>
>>> 'HBASE-25649 Complete the work on moving all the balancer related
>>> classes to hbase-balancer module' is done. The rs group related code is
>>> still in hbase-server, filed HBASE-25953 for tracking the long term work.
>>>
>>> Seems no other big progress...
>>>
>>> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月22日周六 下午4:05写道：
>>>
>>>> FWIW, we should not include a feature which is not ready in the final
>>>> GA release, so finally we need to purge these feature out. For me, I'm fine
>>>> with removing feature in alpha releases, but for beta releases, we should
>>>> not remove features any more.
>>>>
>>>> I was also thinking of making release out of master first, for example,
>>>> the first several alpha releases, and then cut branch-3 for making beta and
>>>> GA releases.
>>>> My concern here is that, as we still accept any patches on master, is
>>>> it possible for us to make it stable enough?
>>>>
>>>> And for upgrading, we should at least support rolling upgrading to 3.x
>>>> from all the active 2.x releases when we cut the first 3.0.0 beta release.
>>>> Rolling upgrading from all 2.x minor releases line will be a nice to have.
>>>>
>>>> Thanks.
>>>>
>>>> Sean Busbey <bu...@apache.org> 于2021年5月22日周六 上午10:47写道：
>>>>
>>>>> I'm happy to see us moving forward with hbase 3 release.
>>>>>
>>>>> If a feature makes it into alpha releases but under evaluation doesn't
>>>>> look
>>>>> ready for use, what's the plan? Back things out and put it into a
>>>>> feature
>>>>> branch?
>>>>>
>>>>> What about making releases out of the master branch until we stabilize
>>>>> the
>>>>> API by starting beta releases?
>>>>>
>>>>> What's our goal for upgrades to 3.0? Any 2.y or some specific minimum?
>>>>> Rolling upgrade?
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 21, 2021, 20:25 张铎(Duo Zhang) <pa...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Oh, I forgot a big break change, moving to log4j2.
>>>>> >
>>>>> > 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月21日周五 下午11:10写道：
>>>>> >
>>>>> > > Since favored nodes is an existing feature, an improvement for an
>>>>> > existing
>>>>> > > feature can come in at a minor release I think, unless you plan to
>>>>> > > completely break the compatibility.
>>>>> > >
>>>>> > > Mallikarjun <ma...@gmail.com> 于2021年5月21日周五 下午10:11写道：
>>>>> > >
>>>>> > >> For multi tenancy with favoured nodes, timeline looks
>>>>> unreasonable for
>>>>> > >> 3.0.
>>>>> > >> Can it be part of later 3.x releases? Or should it wait for 4.0?
>>>>> > >>
>>>>> > >> On Fri, May 21, 2021, 7:30 PM 张铎(Duo Zhang) <
>>>>> palomino219@gmail.com>
>>>>> > >> wrote:
>>>>> > >>
>>>>> > >> > We already have the below big feature/changes for 3.0.0.
>>>>> > >> >
>>>>> > >> > Synchronous Replication
>>>>> > >> > OpenTelemetry Tracing
>>>>> > >> > Distributed MOB Compaction
>>>>> > >> > Backup and Restore
>>>>> > >> > Move RSGroup balancer to core
>>>>> > >> > Reimplement sync client on async client
>>>>> > >> > CPEPs on shaded proto
>>>>> > >> >
>>>>> > >> > There are also some ongoing works which target 3.0.0.
>>>>> > >> >
>>>>> > >> > Splittable meta
>>>>> > >> > Move balancer code to hbase-balancer
>>>>> > >> > Compaction offload
>>>>> > >> > Replication offload
>>>>> > >> >
>>>>> > >> > Since now, we do not even have enough new features to cut a
>>>>> minor
>>>>> > >> release
>>>>> > >> > for 2.x, I think it is time to cut the 3.x release line now,
>>>>> and I
>>>>> > >> think we
>>>>> > >> > already have enough new features for a new major release.
>>>>> > >> >
>>>>> > >> > Here I plan to cut a branch-3 at the end of June and make our
>>>>> first
>>>>> > >> > 3.0.0-alpha1 release, and finally make the 3.0.0 release by the
>>>>> end of
>>>>> > >> > 2021. So if any of the above work can not be done before the
>>>>> end of
>>>>> > >> June,
>>>>> > >> > they will be moved out to 4.0.0.
>>>>> > >> >
>>>>> > >> > Thoughts? Thanks.
>>>>> > >> >
>>>>> > >>
>>>>> > >
>>>>> >
>>>>>
>>>>
Re: Time for 3.0.0 release
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
I've moved all the unfinished issues from 3.0.0-alpha-1 to 3.0.0-alpha-2.
And I remember that there is a discussion in the past, to not include
CHANGES and RELEASENOTES in the release, just use jira to maintain the
release note, so maybe this time we could make this happen?
Thanks.
张铎(Duo Zhang) <pa...@gmail.com> 于2021年6月30日周三 上午11:48写道：
> Kindly reminder that it is time for our first 3.0.0-alpha-1 now.
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月31日周一 下午11:37写道：
>
>> 'HBASE-25649 Complete the work on moving all the balancer related classes
>> to hbase-balancer module' is done. The rs group related code is still in
>> hbase-server, filed HBASE-25953 for tracking the long term work.
>>
>> Seems no other big progress...
>>
>> 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月22日周六 下午4:05写道：
>>
>>> FWIW, we should not include a feature which is not ready in the final GA
>>> release, so finally we need to purge these feature out. For me, I'm fine
>>> with removing feature in alpha releases, but for beta releases, we should
>>> not remove features any more.
>>>
>>> I was also thinking of making release out of master first, for example,
>>> the first several alpha releases, and then cut branch-3 for making beta and
>>> GA releases.
>>> My concern here is that, as we still accept any patches on master, is it
>>> possible for us to make it stable enough?
>>>
>>> And for upgrading, we should at least support rolling upgrading to 3.x
>>> from all the active 2.x releases when we cut the first 3.0.0 beta release.
>>> Rolling upgrading from all 2.x minor releases line will be a nice to have.
>>>
>>> Thanks.
>>>
>>> Sean Busbey <bu...@apache.org> 于2021年5月22日周六 上午10:47写道：
>>>
>>>> I'm happy to see us moving forward with hbase 3 release.
>>>>
>>>> If a feature makes it into alpha releases but under evaluation doesn't
>>>> look
>>>> ready for use, what's the plan? Back things out and put it into a
>>>> feature
>>>> branch?
>>>>
>>>> What about making releases out of the master branch until we stabilize
>>>> the
>>>> API by starting beta releases?
>>>>
>>>> What's our goal for upgrades to 3.0? Any 2.y or some specific minimum?
>>>> Rolling upgrade?
>>>>
>>>>
>>>>
>>>> On Fri, May 21, 2021, 20:25 张铎(Duo Zhang) <pa...@gmail.com>
>>>> wrote:
>>>>
>>>> > Oh, I forgot a big break change, moving to log4j2.
>>>> >
>>>> > 张铎(Duo Zhang) <pa...@gmail.com> 于2021年5月21日周五 下午11:10写道：
>>>> >
>>>> > > Since favored nodes is an existing feature, an improvement for an
>>>> > existing
>>>> > > feature can come in at a minor release I think, unless you plan to
>>>> > > completely break the compatibility.
>>>> > >
>>>> > > Mallikarjun <ma...@gmail.com> 于2021年5月21日周五 下午10:11写道：
>>>> > >
>>>> > >> For multi tenancy with favoured nodes, timeline looks unreasonable
>>>> for
>>>> > >> 3.0.
>>>> > >> Can it be part of later 3.x releases? Or should it wait for 4.0?
>>>> > >>
>>>> > >> On Fri, May 21, 2021, 7:30 PM 张铎(Duo Zhang) <palomino219@gmail.com
>>>> >
>>>> > >> wrote:
>>>> > >>
>>>> > >> > We already have the below big feature/changes for 3.0.0.
>>>> > >> >
>>>> > >> > Synchronous Replication
>>>> > >> > OpenTelemetry Tracing
>>>> > >> > Distributed MOB Compaction
>>>> > >> > Backup and Restore
>>>> > >> > Move RSGroup balancer to core
>>>> > >> > Reimplement sync client on async client
>>>> > >> > CPEPs on shaded proto
>>>> > >> >
>>>> > >> > There are also some ongoing works which target 3.0.0.
>>>> > >> >
>>>> > >> > Splittable meta
>>>> > >> > Move balancer code to hbase-balancer
>>>> > >> > Compaction offload
>>>> > >> > Replication offload
>>>> > >> >
>>>> > >> > Since now, we do not even have enough new features to cut a minor
>>>> > >> release
>>>> > >> > for 2.x, I think it is time to cut the 3.x release line now, and
>>>> I
>>>> > >> think we
>>>> > >> > already have enough new features for a new major release.
>>>> > >> >
>>>> > >> > Here I plan to cut a branch-3 at the end of June and make our
>>>> first
>>>> > >> > 3.0.0-alpha1 release, and finally make the 3.0.0 release by the
>>>> end of
>>>> > >> > 2021. So if any of the above work can not be done before the end
>>>> of
>>>> > >> June,
>>>> > >> > they will be moved out to 4.0.0.
>>>> > >> >
>>>> > >> > Thoughts? Thanks.
>>>> > >> >
>>>> > >>
>>>> > >
>>>> >
>>>>
>>>