Re: [ANNOUNCE] Apache HBase 2.3.5 is now available for download

[Mich Talebzadeh]

Great news HBase team, well done.

I have worked with HBase for many years and I think it is a great product.
it does what it says on the tin so to speak.

Ironically if you look around the NoSQL competitors, most of them are
supported by start-ups, whereas HBase is only supported as part of Apache
suite of products by vendors like Cloudera and others. Moreover, Google
Cloud BigTable (proprietary)  now has a seamless API to Apache HBase.

For those who would prefer to use SQL on top, there is Apache Phoenix
around which makes life easier for most SQL savvy people to work on HBase.
Problem solved

For TCO, HBase is still value for money compared to others. You do not need
expensive RAM or SSD with Hbase. That makes it easy to onboard it in no
time. Also Hbase can be used in a variety of different business
applications, whereas other commercial ones  are focused on narrower niche
markets.

I believe HBase is now on its 11th anniversary (the 10th anniversary was
May 2020) and hope HBase will go from strength to strength and we will
keep using it for years to come with these frequent upgrades.




   view my Linkedin profile




*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.




On Thu, 1 Apr 2021 at 19:58, Huaxiang Sun  wrote:

> The HBase team is happy to announce the immediate availability of HBase
>
> 2.3.5.
>
>
> Apache HBase™ is an open-source, distributed, versioned, non-relational
>
> database.
>
> Apache HBase gives you low latency random access to billions of rows with
>
> millions of columns atop non-specialized hardware. To learn more about
>
> HBase, see https://hbase.apache.org/.
>
>
> HBase 2.3.5 is the fifth patch release in the HBase 2.3.x line, which aims
>
> to improve the stability and reliability of HBase. This release includes 53
> bug
>
> fixes and improvements since 2.3.4.
>
>
> The full list of issues and release notes can be found here:
>
> CHANGELOG: https://downloads.apache.org/hbase/2.3.5/CHANGES.md
>
> RELEASENOTES: https://downloads.apache.org/hbase/2.3.5/RELEASENOTES.md
>
>
> or via our issue tracker:
>
> https://issues.apache.org/jira/projects/HBASE/versions/12349549
>
>
> To download please follow the links and instructions on our website:
>
>
> https://hbase.apache.org/downloads.html
>
>
> Questions, comments, and problems are always welcome at:
>
> d...@hbase.apache.org
>
> user@hbase.apache.org
>
>
> Thanks to all who contributed and made this release possible.
>
>
> Cheers,
>
> The HBase Dev Team
>

[ANNOUNCE] Apache HBase 2.3.5 is now available for download

[Huaxiang Sun]

The HBase team is happy to announce the immediate availability of HBase

2.3.5.


Apache HBase™ is an open-source, distributed, versioned, non-relational

database.

Apache HBase gives you low latency random access to billions of rows with

millions of columns atop non-specialized hardware. To learn more about

HBase, see https://hbase.apache.org/.


HBase 2.3.5 is the fifth patch release in the HBase 2.3.x line, which aims

to improve the stability and reliability of HBase. This release includes 53
bug

fixes and improvements since 2.3.4.


The full list of issues and release notes can be found here:

CHANGELOG: https://downloads.apache.org/hbase/2.3.5/CHANGES.md

RELEASENOTES: https://downloads.apache.org/hbase/2.3.5/RELEASENOTES.md


or via our issue tracker:

https://issues.apache.org/jira/projects/HBASE/versions/12349549


To download please follow the links and instructions on our website:


https://hbase.apache.org/downloads.html


Questions, comments, and problems are always welcome at:

d...@hbase.apache.org

user@hbase.apache.org


Thanks to all who contributed and made this release possible.


Cheers,

The HBase Dev Team

回复： EOL branch-1 and all 1.x ?

[zheng wang]

+1 on EOL.




-- 原始邮件 --
发件人:
"user"  
  

Re: EOL branch-1 and all 1.x ?

[Peter Somogyi]

+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani  wrote:

> +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
> active at all)
>
>
> On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell 
> wrote:
>
> > EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
> > fine to leave that in place. That can be a separate, future, discussion,
> > although if branch-1 becomes EOL its eventual removal would be certain.
> The
> > question is really if we plan to maintain branch-1 going forward. Based
> on
> > lack of interest and demand in releasing it, there does not seem reason
> to.
> >
> >
> > > On Mar 31, 2021, at 7:51 PM, Reid Chan  wrote:
> > >
> > > My only concern is about the performance, once in a while there'll be
> > > some emails like "2.x.y is slower than 1.x.y".
> > >
> > >
> > >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell 
> > wrote:
> > >>
> > >> Is it time to consider EOL of branch-1 and all 1.x releases ?
> > >>
> > >> There doesn't seem to be much developer interest in branch-1 beyond
> > >> occasional maintenance. This is understandable. Per our compatibility
> > >> guidelines, branch-1 commits must be compatible with Java 7, and the
> > range
> > >> of acceptable versions of third party dependencies is also restricted
> > due
> > >> to Java 7 compatibility requirements. Most developers are writing code
> > with
> > >> Java 8+ idioms these days. For that reason and because the branch-1
> code
> > >> base is generally aged at this point, all but trivial (or lucky!)
> > backports
> > >> require substantial changes in order to integrate adequately. Let me
> > also
> > >> observe that branch-1 artifacts are not fully compatible with Java 11
> or
> > >> later. (The shell is a good example of such issues: The version of
> > >> jruby-complete required by branch-1 is not compatible with Java 11 and
> > >> upgrading to the version used by branch-2 causes shell commands to
> error
> > >> out due to Ruby language changes.)
> > >>
> > >> We can a priori determine there is insufficient motivation for
> > production
> > >> of release artifacts for the PMC to vote upon. Otherwise, someone
> would
> > >> have done it. We had 12 releases from branch-2 derived code in 2019,
> 13
> > >> releases from branch-2 derived code in 2020, and so far we have had 3
> > >> releases from branch-2 derived code in 2021. In contrast, we had 8
> > releases
> > >> from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
> > and
> > >> so far 0 releases from branch-1 in 2021.
> > >>
> > >> *  2021202020191.x0282.x31312*
> > >>
> > >> If there is someone interested in continuing branch-1, now is the time
> > to
> > >> commit. However let me be clear that simply expressing an abstract
> > desire
> > >> to see continued branch-1 releases will not be that useful. It will be
> > >> noted, but will not have much real world impact. Apache is a
> do-ocracy.
> > In
> > >> the absence of intrinsic motivation of project participants, which is
> > what
> > >> we seem to have here, you will need to do something: Fix the
> > compatibility
> > >> issues, if any between the last release of 1.x and the current
> branch-1
> > >> head; fix any failing and flaky unit tests; produce release artifacts;
> > and
> > >> submit those artifacts to the PMC for voting. Or, convince someone
> with
> > >> commit rights and/or PMC membership to undertake these actions on your
> > >> behalf.
> > >>
> > >> Otherwise, I respectfully submit for your consideration, it is time to
> > >> declare  branch-1 and all 1.x code lines EOL, simply acknowledging
> what
> > has
> > >> effectively already happened.
> > >>
> > >> --
> > >> Best regards,
> > >> Andrew
> > >>
> > >> Words like orphans lost among the crosstalk, meaning torn from truth's
> > >> decrepit hands
> > >>   - A23, Crosstalk
> > >>
> >
>