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 in 2.2 I think that we should expect that these api breakages happen, and handle these cases as the norm, and have a policy for them. (Not that we shouldn't ask HBase not to break us in a patch level, if it is just for the sake of refactoring) Istvan On Wed, Feb 17, 2021 at 5:49 AM Andrew Purtell <andrew.purt...@gmail.com> wrote: > 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 to blacklist 2.4.1 in your build rather than deal with it. > Then this becomes an issue for a future 2.5 compat module. > > > > On Feb 16, 2021, at 8:38 PM, Viraj Jasani <vjas...@apache.org> 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 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 at 3:28 AM, Andrew Purtell <apurt...@apache.org> > wrote: > >> > >> 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 <apurt...@apache.org> > >> wrote: > >> > >>>> 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 and 2.4.1, we can fix it, and you'll be good > >> again > >>> in 2.4.2 and forward. You could blacklist 2.4.1 in your build of the > 2.4 > >>> compat module using the enforcer plugin if you like. > >>> > >>> If the break was a private interface, but it is a simple issue, like > >>> removal of a constant field, or removal of a method that's easy to put > >> back > >>> for sake of compatibility, we can probably just put it back. By > >> 'probably' > >>> I mean I would not be opposed to it but there's always the chance that > >>> someone would object. > >>> > >>> > >>>> On Tue, Feb 16, 2021 at 4:07 AM Viraj Jasani <vjas...@apache.org> > wrote: > >>> > >>>> 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 version always support latest supported > >> HBase > >>>> compat module and HBase patch release (e.g in our case, profile 2.4 > uses > >>>> compat-module 2.4.1, and profile 2.4.0 uses compat module 2.4.0) > >>>> 3. We run jenkins tests only for latest minor release profiles (e.g > with > >>>> profiles 2.4 and 2.4.0 in place, we run tests for profile 2.4 only, > >> which > >>>> points to latest version 2.4.1) > >>>> > >>>> HBase profile to build compatibility examples: > >>>> > >>>> *Profile for HBase minor version:* > >>>> 2.1 (supports all 2.1.x releases), > >>>> 2.3 (supports all 2.3.x releases), > >>>> 2.4 (if we have profile 2.4.0, 2.4 profile supports 2.4.1+ releases > and > >>>> not > >>>> 2.4.0) > >>>> > >>>> *Profile for HBase patch version:* > >>>> 2.4.0 (supports only 2.4.0 release) > >>>> > >>>> Thoughts? > >>>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Andrew > >>> > >>> Words like orphans lost among the crosstalk, meaning torn from truth's > >>> decrepit hands > >>> - A23, Crosstalk > >>> > >> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >> > -- *István Tóth* | Staff Software Engineer st...@cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
