On 05.02.23 16:52, Neil C Smith wrote:
On Wed, 11 Jan 2023 at 11:03, Neil C Smith <neilcsm...@apache.org> wrote:
Yes, the sooner we can update what was agreed for NB13, the better.
But that requires notice (so not NB17, and possibly not NB18), a new
lazy consensus proposal, and no vetoes!
Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
While the immediate NB17 issue was resolved, but given comments in
other threads more recently, it would be good not to let the
discussion on when and how to drop the rest of our JDK 8 support. In
particular with JDK 21 (the next LTS) already on the horizon later
this year.
In the past I believe NetBeans supported current and previous Java
releases? Now might be the time to consider what our long term plan
with the new JDK release schedule should be too. Previously we've
discussed LTS-1, LTS and current as perhaps the limit of our capacity,
for both maintaining and testing infrastructure?
Firstly, do we look to move to JDK 11 as the baseline release for
compilation, and running of all modules from NetBeans 19 (Aug 2023)?
That allows us to advertise the NetBeans 18 platform as the last
release that will support JDK 8, as well as give us time to look at
remaining problems with tests?
would be great. The JDK 8 -> 11 step is in many ways "special" since so
much changed between those two LTS releases.
I don't think we have to move everything to JDK 11 at once - so even if
we have the odd test left which requires JDK 8, it shouldn't hold
anything back IMO.
We can move modules to JDK 11 incrementally until nothing is left on JDK
8. NB already requires JDK 11 as runtime, what we should do next is to
communicate that the same rule applies for the platform.
I thought so far that the NB VSCode extension would still have a hard
JDK 8 requirement - but I was wrong as this discussion showed, so there
is nothing stopping us from doing this except the rule we set ourself in
past.
We should also consider a dialog for NB 18 which warns users if they try
to run NB on JDK 8 - we still don't have that dialog, I somehow keep
forgetting about it and only get reminded again while reading the issue
tracker during the RC phase.
Secondly, should we at the same time advertise a plan for future JDK
support so that IDE and platform users have something concrete to work
with? This could be based on LTS-1, LTS and current. We could take
the release of JDK 22, when JDK 21 stops being "current", as the point
where we drop support for JDK 11. That would have NetBeans 22 (May
2024) requiring JDK 17 for build and run.
We don't have to make this a hard rule. I would move to the next LTS as
soon it makes sense and we are actually able to do it. Once this works
we can make a rule out of it :)
We have required JDK 11 for build some time before dropping JDK 8
support. Do we go back to min JDK for build and run being the same
again, moving build and run min JDK 17 at the same time, or staggered?
i believe we should keep build and runtime requirements close to each
other when possible to simplify the whole process.
However, depending on how quick we update that minimum JDK requirement
in future, it might diverge again in rare situations.
example:
- Spring requires JDK 17 already
- Jakarta EE 11 will target JDK 21 (whatever "target" means, might be
vendor dependent, nobody could explain this to me so far)
So we might end up having modules wich require a more recent version
again. I would be always in favor to bump everything to the next LTS but
if we can't for whatever reason, this should not stop individual modules
from doing that IMO.
i was hoping to be able to implement one 'release' property in the build
which would define the default bytecode level for everything and remove
the source/target properties everywhere. Modules would only define a
'release' version if they want to break that convention.
we had some discussions about this here:
https://github.com/apache/netbeans/pull/5122
best regards,
michael
Thoughts? Concerns? Alternatives?
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
