Re: EOL branch-1 and all 1.x ?
+1 to EOL'ing branch-1 and all other branch-1.x too (if they are still active at all) On Thu, 1 Apr 2021 at 8:53 AM, Andrew Purtell wrote: > EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be > fine to leave that in place. That can be a separate, future, discussion, > although if branch-1 becomes EOL its eventual removal would be certain. The > question is really if we plan to maintain branch-1 going forward. Based on > lack of interest and demand in releasing it, there does not seem reason to. > > > > On Mar 31, 2021, at 7:51 PM, Reid Chan wrote: > > > > My only concern is about the performance, once in a while there'll be > > some emails like "2.x.y is slower than 1.x.y". > > > > > >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell > 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 > >> >
Re: EOL branch-1 and all 1.x ?
EOL of branch-1 doesn’t mean we take down the 1.6.0 release. It would be fine to leave that in place. That can be a separate, future, discussion, although if branch-1 becomes EOL its eventual removal would be certain. The question is really if we plan to maintain branch-1 going forward. Based on lack of interest and demand in releasing it, there does not seem reason to. > On Mar 31, 2021, at 7:51 PM, Reid Chan wrote: > > My only concern is about the performance, once in a while there'll be > some emails like "2.x.y is slower than 1.x.y". > > >> On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell 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 >>
Re: EOL branch-1 and all 1.x ?
My only concern is about the performance, once in a while there'll be some emails like "2.x.y is slower than 1.x.y". On Thu, Apr 1, 2021 at 6:03 AM Andrew Purtell 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 >
Re: EOL branch-1 and all 1.x ?
Thanks for the write-up Andrew. +1 on its EOL'ing. S On Wed, Mar 31, 2021 at 3:03 PM Andrew Purtell 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 >
EOL branch-1 and all 1.x ?
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
