+1 for EOL branch-1.4

Thanks for the works

On Wed, Oct 13, 2021 at 1:39 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote:

> Filed HBASE-26355 for releasing 1.4.14.
>
> 张铎(Duo Zhang) <palomino...@gmail.com> 于2021年10月11日周一 下午5:31写道:
>
> > So I think in this thread, the only concern is about performance issues,
> > so we decided to make new releases on branch-1.
> >
> > But at least I think we all agree to EOL other 1.x release lines,
> > especially branch-1.4 right?
> >
> > If no other concerns, let's do a final 1.4.14 release and then mark
> > branch-1.4 as EOL. There are 40 issues under 1.4.14 so I think it is
> worth
> > having a new release.
> >
> > Thanks.
> >
> > Andrew Purtell <andrew.purt...@gmail.com> 于2021年6月1日周二 上午3:16写道:
> >
> >> 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
> >> >>>
> >> >>
> >>
> >
>

Reply via email to