Re: Time for 3.0.0 release
Oh, it is this issue. https://issues.apache.org/jira/browse/HBASE-25520 Let's get this done. 张铎(Duo Zhang) 于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) 于2021年6月30日周三 上午11:48写道: > >> Kindly reminder that it is time for our first 3.0.0-alpha-1 now. >> >> 张铎(Duo Zhang) 于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) 于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 于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) > wrote: > > > Oh, I forgot a big break change, moving to log4j2. > > > > 张铎(Duo Zhang) 于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 于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) < > palomino...@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
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) 于2021年6月30日周三 上午11:48写道: > Kindly reminder that it is time for our first 3.0.0-alpha-1 now. > > 张铎(Duo Zhang) 于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) 于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 于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) wrote: > Oh, I forgot a big break change, moving to log4j2. > > 张铎(Duo Zhang) 于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 于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) >>> > > >> 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
Kindly reminder that it is time for our first 3.0.0-alpha-1 now. 张铎(Duo Zhang) 于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) 于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 于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) wrote: >>> >>> > Oh, I forgot a big break change, moving to log4j2. >>> > >>> > 张铎(Duo Zhang) 于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 于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) >>> > >> 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
'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) 于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 于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) wrote: >> >> > Oh, I forgot a big break change, moving to log4j2. >> > >> > 张铎(Duo Zhang) 于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 于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) >> > >> 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
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 于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) wrote: > > > Oh, I forgot a big break change, moving to log4j2. > > > > 张铎(Duo Zhang) 于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 于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) > > >> 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
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) wrote: > Oh, I forgot a big break change, moving to log4j2. > > 张铎(Duo Zhang) 于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 于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) > >> 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
Oh, I forgot a big break change, moving to log4j2. 张铎(Duo Zhang) 于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 于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) >> 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
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 于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) 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
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) 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. >
Time for 3.0.0 release
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.