On Sun, 5 Feb 2023 at 19:12, Michael Bien <mbie...@gmail.com> wrote:
> would be great. The JDK 8 -> 11 step is in many ways "special" since so
> much changed between those two LTS releases.

Well, yes, otherwise we might have done this some time ago! :-)

> I don't think we have to move everything to JDK 11 at once -
...
> We can move modules to JDK 11 incrementally until nothing is left on JDK
> 8.

Isn't that the status quo? Having a few modules opting in to JDK 11
seems a bit different to moving towards having everything opt-in and
losing the benefits of a default configuration.  At some point we
surely need to move the default configuration up to JDK 11?

> 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.

Yes, so it's hopefully time to consider the next iteration of that rule ...

> 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 :)

Who said "hard rule"?  Our release schedule and process (which this
ties into) was agreed to try and provide consistency and clarity for
ourselves and users.  But it's iterated multiple times since.  Part of
the thoughts on this are because OpenJDK iterated its release and
support schedule.  Having some principle that we can agree and can
advertise to end users, particularly platform and plugin developers,
has benefit.

Let me reword the suggestion a little - the only two hard guarantees would be to
- a) support running the platform on JDK 8 until NetBeans 19
- b) to commit to supporting building and running on JDK 11 until (at
least?) NetBeans 22 / May 2024

We don't need to commit to raising the bytecode version straight away,
true, just it becomes an option at that point - we could also have a
soft requirement as now.

> 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.

Yes, saw that and totally agree.  Isn't that an argument for not
taking the opt-in approach above though?

> 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.

You and me both!  :-)  I'm almost thinking it might not be worth it -
depends how we approach in future and whether it has re-use.

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



Reply via email to