You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by zheng wang <18...@qq.com> on 2021/04/01 14:45:19 UTC

回复: EOL branch-1 and all 1.x ?

+1 on EOL.




------------------&nbsp;原始邮件&nbsp;------------------
发件人:                                                                                                                        "user"                                                                                    <psomogyi@apache.org&gt;;
发送时间:&nbsp;2021年4月1日(星期四) 晚上9:24
收件人:&nbsp;"HBase Dev List"<dev@hbase.apache.org&gt;;
抄送:&nbsp;"hbase-user"<user@hbase.apache.org&gt;;
主题:&nbsp;Re: EOL branch-1 and all 1.x ?



+1 on EOL.

On Thu, Apr 1, 2021 at 7:32 AM Viraj Jasani <vjasani@apache.org&gt; wrote:

&gt; +1 to EOL'ing branch-1 and all other branch-1.x too (if they are still
&gt; active at all)
&gt;
&gt;
&gt; On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell <andrew.purtell@gmail.com&gt;
&gt; wrote:
&gt;
&gt; &gt; EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be
&gt; &gt; fine to leave that in place. That can be a separate, future, discussion,
&gt; &gt; although if branch-1 becomes EOL its eventual removal would be certain.
&gt; The
&gt; &gt; question is really if we plan to maintain branch-1 going forward. Based
&gt; on
&gt; &gt; lack of interest and demand in releasing it, there does not seem reason
&gt; to.
&gt; &gt;
&gt; &gt;
&gt; &gt; &gt; On Mar 31, 2021, at 7:51 PM, Reid Chan <reidchan0301@gmail.com&gt; wrote:
&gt; &gt; &gt;
&gt; &gt; &gt; My only concern is about the performance, once in a while there'll be
&gt; &gt; &gt; some emails like "2.x.y is slower than 1.x.y".
&gt; &gt; &gt;
&gt; &gt; &gt;
&gt; &gt; &gt;&gt; On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell <apurtell@apache.org&gt;
&gt; &gt; wrote:
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Is it time to consider EOL of branch-1 and all 1.x releases ?
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; There doesn't seem to be much developer interest in branch-1 beyond
&gt; &gt; &gt;&gt; occasional maintenance. This is understandable. Per our compatibility
&gt; &gt; &gt;&gt; guidelines, branch-1 commits must be compatible with Java 7, and the
&gt; &gt; range
&gt; &gt; &gt;&gt; of acceptable versions of third party dependencies is also restricted
&gt; &gt; due
&gt; &gt; &gt;&gt; to Java 7 compatibility requirements. Most developers are writing code
&gt; &gt; with
&gt; &gt; &gt;&gt; Java 8+ idioms these days. For that reason and because the branch-1
&gt; code
&gt; &gt; &gt;&gt; base is generally aged at this point, all but trivial (or lucky!)
&gt; &gt; backports
&gt; &gt; &gt;&gt; require substantial changes in order to integrate adequately. Let me
&gt; &gt; also
&gt; &gt; &gt;&gt; observe that branch-1 artifacts are not fully compatible with Java 11
&gt; or
&gt; &gt; &gt;&gt; later. (The shell is a good example of such issues: The version of
&gt; &gt; &gt;&gt; jruby-complete required by branch-1 is not compatible with Java 11 and
&gt; &gt; &gt;&gt; upgrading to the version used by branch-2 causes shell commands to
&gt; error
&gt; &gt; &gt;&gt; out due to Ruby language changes.)
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; We can a priori determine there is insufficient motivation for
&gt; &gt; production
&gt; &gt; &gt;&gt; of release artifacts for the PMC to vote upon. Otherwise, someone
&gt; would
&gt; &gt; &gt;&gt; have done it. We had 12 releases from branch-2 derived code in 2019,
&gt; 13
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2020, and so far we have had 3
&gt; &gt; &gt;&gt; releases from branch-2 derived code in 2021. In contrast, we had 8
&gt; &gt; releases
&gt; &gt; &gt;&gt; from branch-1 derived code in 2019, 0 releases from branch-1 in 2020,
&gt; &gt; and
&gt; &gt; &gt;&gt; so far 0 releases from branch-1 in 2021.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; *&nbsp; 2021202020191.x0282.x31312*
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; If there is someone interested in continuing branch-1, now is the time
&gt; &gt; to
&gt; &gt; &gt;&gt; commit. However let me be clear that simply expressing an abstract
&gt; &gt; desire
&gt; &gt; &gt;&gt; to see continued branch-1 releases will not be that useful. It will be
&gt; &gt; &gt;&gt; noted, but will not have much real world impact. Apache is a
&gt; do-ocracy.
&gt; &gt; In
&gt; &gt; &gt;&gt; the absence of intrinsic motivation of project participants, which is
&gt; &gt; what
&gt; &gt; &gt;&gt; we seem to have here, you will need to do something: Fix the
&gt; &gt; compatibility
&gt; &gt; &gt;&gt; issues, if any between the last release of 1.x and the current
&gt; branch-1
&gt; &gt; &gt;&gt; head; fix any failing and flaky unit tests; produce release artifacts;
&gt; &gt; and
&gt; &gt; &gt;&gt; submit those artifacts to the PMC for voting. Or, convince someone
&gt; with
&gt; &gt; &gt;&gt; commit rights and/or PMC membership to undertake these actions on your
&gt; &gt; &gt;&gt; behalf.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Otherwise, I respectfully submit for your consideration, it is time to
&gt; &gt; &gt;&gt; declare&nbsp; branch-1 and all 1.x code lines EOL, simply acknowledging
&gt; what
&gt; &gt; has
&gt; &gt; &gt;&gt; effectively already happened.
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; --
&gt; &gt; &gt;&gt; Best regards,
&gt; &gt; &gt;&gt; Andrew
&gt; &gt; &gt;&gt;
&gt; &gt; &gt;&gt; Words like orphans lost among the crosstalk, meaning torn from truth's
&gt; &gt; &gt;&gt; decrepit hands
&gt; &gt; &gt;&gt;&nbsp;&nbsp; - A23, Crosstalk
&gt; &gt; &gt;&gt;
&gt; &gt;
&gt;