It would be good to do the performance work at least, if you are up for it. There are always going to be consequences for the kind of significant evolution that 2.x represents over 1.x.
Regarding performance, a change always has positive and negative consequences. It is important to understand them both, informed by real world use cases. My guess is you have real world use cases, Reid. Your results will be meaningful. Synthetic benchmarks are less interesting unless the regression is obvious and more like a bug than a consequence. Sure they will report positive and negative changes, but does that actually mean anything? It depends. Sometimes it will only mean something if we care about supporting the synthetic benchmark as a first class use case. (Usually we don’t; but universal cross system bench tools like YCSB are exceptions.) > On May 31, 2021, at 9:25 AM, Reid Chan <reidchan0...@gmail.com> wrote: > > Thanks to Andrew and Sean's help, I managed to release the first candidate > of 1.7.0 (at least it is a beginning, and graduated from green hand). > BTW, The [VOTE] > <https://lists.apache.org/thread.html/r0b96b6596fc423e17ff648633e5ea76fd897d9afb8a03ae6e09cdb8f%40%3Cdev.hbase.apache.org%3E> > > The following are my thoughts: > I'm willing to continue branch-1's life as a RM. > And before EOL branch-1, I need to announce EOL of branch-1.4. > While maintaining the branch-1, I also will do some benchmarks between 1.7+ > and 2.4+ (the latest). If 2.4+ is better, cool. Otherwise, I'm willing to > spend some time diving in. > After the performance issue is done, I need to review the upgrade from 1.x > to 2.x. I remember someone wrote it. But HBASE-25902 seems to reveal some > problems already. > I will announce EOL of branch-1 if listed above are done. > > Probably more than 1 year, by estimation, if I have to do it all alone. The > most time-spending should be performance diving in (if there was) and > upgrade review. > > Any thought is appreciated. > > > --- > Best regards, > R.C > > > > >> On Tue, Apr 20, 2021 at 12:13 AM Reid Chan <reidchan0...@gmail.com> wrote: >> >> >> FYI, a JDK issue when I was making the 1.7.0 release. >> >> >> https://lists.apache.org/thread.html/r118b08134676d9234362a28898249186fe73a1fb08535d6eec6a91d3%40%3Cdev.hbase.apache.org%3E >> >> >> --- >> Best Regards, >> R.C >> >>> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <apurt...@apache.org> 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 >>> >>
