> With all due respect, that's not an "alternative". It took me two
I believe my proposal is a real alternative and it is a way to move us forward while not giving up on what makes NetBeans Platform unique - while not giving up on backward compatibility. > reads to distinguish it from the status quo that we've been doing for > the last 18 months. Even then, in practical terms, it's the same. If The core of my alternative proposal is to move forward and support newer JDKs properly, where needed via the "Run on JDK8, use JDK11 APIs!" - http:// wiki.apidesign.org/wiki/AlternativeImplementation Are you saying we are using this proposal already for last 18 months? I am not aware of that! If I am mistaken, then please point me to few PRs that are implementing the "Run on JDK8, use JDK11 APIs!" technique! I haven't seen this "Run on JDK8, use JDK11 APIs!" used yet! To let us start, please give me three problems that could be solved by using JDK 11 APIs and I'll create a PR showing how to do that properly via the "Run on JDK8, use JDK11 APIs!" style. You will all see, it is a simple and viable way to move forward. Then we can all copy that approach where needed and you can focus on what you care about... > maintenance of the JDK 8 tests is something ...none of you wants to do. I understand that. You want to focus on what you like. Great, go on and focus fully on new JDKs. I'll maintain the old modules/ tests for you. I don't find that particularly fascinating, but NetBeans Platform backward compatibility is so close to my heart that I am going to sacrifice myself and do this dirty work. At the end, keeping exiting, functional code running, isn't going to be that much work. TL;DR: If my alternative proposal is accepted, we'll start doing things differently and allow the NetBeans project to move forward while keeping its heritage and compatibility. Best regards. -jt Dne čtvrtek 6. dubna 2023 10:16:14 CEST, Neil C Smith napsal(a): > On Wed, 5 Apr 2023 at 16:13, Jaroslav Tulach <jaroslav.tul...@gmail.com> wrote: > > Alternative: > > > > - I will maintain what ever needs to be maintained to keep JDK 8 CI tests > > running > > > > - From Apache NetBeans 19, the minimum JDK required to build and run > > the IDE will be JDK 11. > > > > - The minimum JDK to run and test the NetBeans Platform and modules up to > > VSCode & Jackpot remains JDK 8. > > > > - Usage of JDK11, JDK17, etc. API is possible in dedicated modules via > > http:// wiki.apidesign.org/wiki/AlternativeImplementation > > With all due respect, that's not an "alternative". It took me two > reads to distinguish it from the status quo that we've been doing for > the last 18 months. Even then, in practical terms, it's the same. If > that was actually working and sustainable, we wouldn't be having all > the discussion on this in the first place. > > It doesn't address any of the main concerns. It's already been > pointed out that the maintenance of the JDK 8 tests is something of a > red herring (I would point out you made a similar promise under the > current policy, but didn't input into the EE 10 issue raised in the > background). > > - How do we handle the issue of currently non-optional modules that > require JDK 11+, and who is doing the actual work to split them into > alternative implementations? What happens if there is no viable JDK 8 > implementation? > - How do we address the issue of older / unsupported dependencies (eg. > Lucene, but more inbound) that require a higher JDK? Who is going to > do that work? > - How do we handle issues of testing capacity, both ASF's limited CI > resources and people, and the developer time needed to address > problems raised on JDK 8 when adding new features and support for JDK > 21+? > - How do we address the issue of contributor disengagement, > particularly amongst our most active contributors? Who do you expect > to pick all that work up? > - And, bluntly, from my perspective, who's taking over release > management for NB19+? > > I said I would try and address reasons for blocking consensus by > adapting the proposal. I will continue to do so if other concerns are > raised. But I think it's fundamentally impossible to reconcile your > points with the points raised by others. Therefore, I guess this > sadly but inevitably moves to a vote thread after we close discussion > on Monday. > > > The minimum JDK to run and test the NetBeans Platform and modules up to > > VSCode... remains JDK 8. > > I don't want to pre-empt Martin's input, which I know is coming, but > it has been stated multiple times that dropping JDK 8 is not a problem > for the VSCode plugin ongoing. Other aspects of this proposal I know > from correspondence may be of concern, and therefore may lead to > amendments before any vote. > > > Justification: > ... > > > There's transitivity of non-portability - the portability of the final > > application cannot be bigger than portability of the least portable > > library > > used. > > Couldn't say it any better myself! :-) > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
