Geoffrey, Absolutely. 80% of this patch is dealing with 1.3. 1.4 vs 1.5 affects two or three java files.
My game plan is to submit two different patches, a small one for 1.4 and 1.5 support, and a bigger one other that adds 1.3, so that it can be reverted easily after 1.3 is dropped. I think that maintaining a separate 1.3 branch is the least desirable outcome, as we'd still have two 4.x branches to maintain, with different jenkins jobs, and slightly different jar names and maven artifact structure. Of course the easiest route is to just drop 1.3 support ASAP, and then unify 1.4 and 1.5 . If we are not ready to drop 1.3 very soon, I'd vote for unifying with 1.3 included (I've finished the hard part), and then reverting a lot of the compatibility cruft when we drop 1.3 support. As for the 4.15 maintenance releases, those could stay on the current branches, as we probably want point releases to be drop-in compatible, and the unified version changes the maven artifact versioning, and some jar filenames. This would be one way to extend some support for 1.3 regards István On 2020. 02. 19. 19:11, Geoffrey Jacoby wrote: > Istvan, > > The HBase community has been on the verge of EOLing 1.3 for some time > now -- are there significant gains or simplification if we either end > 1.3 support in Phoenix before PHOENIX-5721 goes in, or alternately, > don't include it in the unified profile since it will be EOLed in the > not-too-distant-future even if we don't do it now? > > Geoffrey > > On Wed, Feb 19, 2020 at 5:36 AM Istvan Toth <[email protected] > <mailto:[email protected]>> wrote: > > Now I have an unpolished version of the unified 4.x branch at > https://github.com/stoty/phoenix/tree/PHOENIX-5721 > > It takes the same approach as the master branch, though there are a bit > more differences to hide in the versions. > > I need to finish the assembly stuff, go over once more the changes, > and run > full ITs on each profile, but I expect that > the Java code will mostly see whitespace changes, so you can check the > logic behind the changes. > > The HBase metrics stuff in particular is interesting, because the whole > feature is missing from 1.3, so it can be used as an example on how > we can > adopt new HBase features later. > > On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth <[email protected] > <mailto:[email protected]>> wrote: > > > Created PHOENIX-5721 > <https://issues.apache.org/jira/browse/PHOENIX-5721> to > > track this. > > > > On Mon, Feb 10, 2020 at 8:21 AM István Tóth <[email protected] > <mailto:[email protected]>> wrote: > > > >> Thanks for the feedback, Geoffrey. > >> > >> I took the lazy option of just creating compatibility methods to > paper > >> over the HBase API changes (emulate the latest version) when we > are calling > >> into HBase. > >> > >> For the APIs implemented by Phoenix, I added compatibility > superclasses. > >> So I expect that we will be able to add a dummy > RegionObserver.preWALAppend > >> to the compatibility coprocessor superclass(es), so that the same > code > >> compiles for older versions as well. > >> > >> Of course if other code paths depend on having that > functionality, those > >> should also be gated by similar compatibility shims/version checks. > >> > >> My current approach is a quick fix, and does not preclude (in fact it > >> enables) later efforts at refactoring/cleanup. > >> > >> On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby > <[email protected] <mailto:[email protected]>> > >> wrote: > >> > >>> If unification could be done, that would be great. (I apologize > that I > >>> haven't had the bandwidth over the past week or two to take a > close look > >>> at > >>> the work Istvan has been doing to unify the 5.x branches -- as > one who > >>> spends too much time cherry-picking I very much appreciate this > effort! > >>> :-) > >>> ) > >>> > >>> I still think the hardest part, as I think I mentioned in some > previous > >>> thread, is what to do when the HBase coprocs themselves diverge > between > >>> minor versions, as they can do. How do you handle the fact that > >>> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4, > and will > >>> exist in 2.3 but not 2.2 and 2.1? And that therefore any > features that > >>> depend on preWALAppend existing (none yet, but they're coming > later this > >>> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or > 2.2 one? > >>> > >>> Since our coprocessors tend to be giant monoliths, trying to create > >>> release-based versions of them selectable by maven profile would > >>> either require lots of developer copy/paste for each change, or a > >>> significant (probably long overdue) refactor to make the coprocs > small > >>> shims that call out to smaller, fine-grained classes that can > >>> occasionally > >>> be release-specific. > >>> > >>> Geoffrey > >>> > >>> On Fri, Feb 7, 2020 at 9:31 AM Josh Elser <[email protected] > <mailto:[email protected]>> wrote: > >>> > >>> > Sounds like a good idea to me. > >>> > > >>> > On 2/6/20 8:40 AM, Istvan Toth wrote: > >>> > > Hello! > >>> > > > >>> > > Now that we have a working solution in master for handling > different > >>> > HBase > >>> > > minor versions, I think that we should think about applying > the same > >>> > > template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5 > >>> branches. > >>> > > > >>> > > Are there any intentional differences between the branches, > apart > >>> from > >>> > > having to conform to the slightly different APIs ? > >>> > > If there are, what are they, and are they considered blockers? > >>> > > > >>> > > Any other reasons not do this ? > >>> > > > >>> > > I expect that based on my experience with the master branch, > I can do > >>> > this > >>> > > in a few days, but I don't want to put in the effort if > there is no > >>> > > interest in it. > >>> > > > >>> > > My plan is to take the 1.5 branch as a base. > >>> > > > >>> > > best regards > >>> > > Istvan > >>> > > > >>> > > >>> > >> > >> > >> -- > >> *István Tóth* | Sr. Software Engineer > >> t. (36) 70 283-1788 > >> [email protected] <mailto:[email protected]> > <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/> > >> ------------------------------ > >> > > >
