I agree that having such a policy does place a burden on us, and we need to
balance the commitments we make and the workload it generates
versus the greater user confidence and possible increased adoption that it
could result in.
I feel that publishing such guidelines, and sticking to them ( as we
+u...@phoenix.apache.org
I wouldn't suggest making any strict policies for ourselves and
doing any promise to the user on the support of EOL HBase versions.
As it may become a burden down the line for us and then sometimes require
an exemption
if we can't make a feature work with a certain release
I'm not sure I understand, let me rephrase
So we drop support right after we release a Phoenix minor version,
if the Phoenix release date is more than a year after the HBase EOL date ?
That sounds fine to me.
How about patch releases ?
I feel that we should not drop Hbase release support in a pa
IMO, we should consider one year grace period plus one minor release? For
example, if we have a new 4.17.0 release in September 2021, we should not
support HBase 1.3(was EOL in Aug 2020) since it passes one year grace
period and one more release support. This means we will include HBase 1.4
and 2.2
I'd request that we keep hbase-2.2 support around for a while longer. If
we drop that, it's going to cause us some major headache whereas I'd
rather see us able to keep pushing our dayjob efforts directly into
upstream.
On 1/28/21 11:56 PM, Viraj Jasani wrote:
+1(non-binding) to EOLing the su
Having a formal policy on maintaining HBase support would provide a peace
of mind to users.
* When do we drop support for minor HBase releases ?
* As soon as they are EOL ?
* Do we want to declare a grace period ?
* What happens if a new HBase patch release is incompatible ?
* We may want to
+1(non-binding) to EOLing the support for HBase 1.3 and 2.1 at least since
both were EOLed last year (1.4 and 2.2 can also be dropped).
Moreover, b/ 2.4.0 and 2.4.1 we have some compat issue in IA.Private class
(we need some utility from HStore which is refactored in 2.4.1), hence we
will need new
+1. Following 4.16 and 5.1's releases I'd suggest EOLing support for HBase
1.3, 1.4, 2.1 and 2.2, I believe all of which have been EOLed by the HBase
community. All of those versions also require special compatibility lib
support currently.
Geoffrey
On Thu, Jan 28, 2021 at 6:35 PM Xinyi Yan wrot
Hi,
I'm thinking to drop the number of supported HBase versions for future
releases. For example, the HBase 1.3 was EOM'd in August 2020, do we still
consider support it for 4.17.0? Similarly, our current master branch also
supports EOM'd HBase version. If phoenix users already upgraded their
HBas
