Istvan,
What makes the case tricky is that the broken class is IA.Private. HBase
has set out compatibility guidelines about what is and isn't safe for
external projects to depend upon, and in this particular case it looks like
we were trying to do something using an IA.Private API that isn't safe
Putting back the methods for 2.4.2 and blacklisting 2.4.1 could be a
solution for this specific case. (thanks for the offer)
However similar past changes were more involved, where this wouldn't be an
option. The last two that I remember:
- multi-join support in 2.0, 2.1, 2.2
- raw filter support i
If you opened a PR that puts the HStore methods back, marks them @Deprecated,
and implements them by calling the new StoreUtil methods, I would approve it.
Just for branch-2.4. Call it a courtesy for Phoenix.
Assuming this gets released in 2.4.2, around the end of the month, then you
could opt
But yes, chances are, someone could object.
On Wed, 17 Feb 2021 at 10:07 AM, Viraj Jasani wrote:
> Thanks Andrew! That’s it, HBASE-25249 is the only refactoring that broke
> compat and since HStore is IA.Private, I could not argue from HBase side to
> bring methods back in HStore. If we can do
Thanks Andrew! That’s it, HBASE-25249 is the only refactoring that broke
compat and since HStore is IA.Private, I could not argue from HBase side to
bring methods back in HStore. If we can do it in 2.4.2, that would be great
and we can skip 2.4.1 support i think.
WDYT Istvan?
On Wed, 17 Feb 2021
Hmm... I see. This thread is probably about PHOENIX-6359, so the change was
HBASE-25249.
The methods moved from HStore to StoreUtils can be added back to HStore as
compatibility methods in branch-2.4.
Is there more?
On Tue, Feb 16, 2021 at 1:34 PM Andrew Purtell wrote:
> > While supporting a
> While supporting a new HBase patch release version (e.g 2.4.1), if it
turns out to be incompatible with existing HBase minor release profile (e.g
profile 2.4), we might have to consider some extra steps.
What happened? If we broke something in a public or limited private
interface between 2.4.0
> Another question is whether we want to publish binary releases for the
> 'old' patch releases, i.e. 2.4.0.
Since we have compat module available (2.4.0), we might want to release it
too, but on the other hand, if we don't have active jenkins tests running
on a regular basis for old patch release
Hi!
I like this solution.
Another question is whether we want to publish binary releases for the
'old' patch releases, i.e. 2.4.0.
BTW 2.2 and 2.1 doesn't support all releases, 2.2 requires HBase 2.2.5+,
and 2.1 requires HBase 2.1.6+,
we didn't keep the old compatibility modules during developme
Hi,
While supporting a new HBase patch release version (e.g 2.4.1), if it turns
out to be incompatible with existing HBase minor release profile (e.g
profile 2.4), we might have to consider some extra steps.
Proposals:
1. Add a new profile for each compat module
2. Profile with HBase minor versio
chrajeshbabu commented on pull request #88:
URL: https://github.com/apache/phoenix-omid/pull/88#issuecomment-779787578
The test failures are not related to it.
This is an automated message from the Apache Git Service.
To resp
Anoop Sam John created PHOENIX-6385:
---
Summary: Not to use Scan#setSmall for HBase 2.x versions
Key: PHOENIX-6385
URL: https://issues.apache.org/jira/browse/PHOENIX-6385
Project: Phoenix
Iss
12 matches
Mail list logo
