Thank you, it is good to hear such feedback from time to time.
#1 - That shall be a question to the community, but I do not see
anything against to support if nothing else the platform on JDK8 for a
long while. Though I'd be happy if we can get rid of patches/workarounds
made for pre-JDK8-s. There are a few UI ones. And as though not in the
platform, but probably we shall remove the support for the 1.5 JVM
profiling as it is parallel with the 1.6+ JVM profiling thing we have.
#2 - I feel as well that the versioning scheme should be fixed somehow.
The current scheme is confusing, unfortunately changing the current
scheme just a little would be more confusing. Probably we shall really
go with date based version numbers...
#3 - Huh, that would be a though one. Righ now LTS is supported until
the next LTS. If we produce one LTS per year, with 3 year support that
would mean we need to support 3 releases at the same time. That again
needs to be discusses in the community, I'm sure that with the current
setup we have no resources for that. Actually I'd be happy if we can
prove that we are able to make regular patch releases to the LTS first.
#4 - That's true, probably we can set up some process to decide what can
and cannot go into the platform. Flatlaf was my bad we can mode it out
somewhere else. Batik on the other hand brings the SVG support, and
actually those libs are heavy. I do not know if we can separate those
out, but we need that HiDPI support.
On 6/23/20 6:56 AM, Jaroslav Tulach wrote:
Hello Neil,
I'd like to understand what my colleagues requirements on LTS are as well!
There seems to be some inherent mismatch when we talk about it, so I am not
really sure. But let's try:
#1 - we need support for JDK8 - everytime we upgrade I have to prove that
JDK8 is still supported and treated seriously. There is a fear that Apache
NetBeans community drops support for JDK8 and we'll be stuck with some
ancient version of NetBeans Platform.
#2 - LTS releases: GraalVM also uses x.0, x.1, x.2, x.3 versioning scheme
however the LTS version is x.3 - my colleagues find it hard to understand
that NetBeans LTS is 12.0 which is just a bugfix version on top of 11.3.
#3 - LTS should last long. At least for three years like Ubuntu. It seems
to me that there is a fear of upgrading. Ideally my colleagues would like
to get just bugfixes without essential upgrades
#4 - growing platform - VisualVM guys and IGV guys complained that 11.3 &
12.0 platform is too big - that it now contains Batik & FlatL&F - in
general people don't want the platform to grow.
That's what I remember right now. Once we switch to 12.0 (autumn?), we'll
need bugfixes that would become 12.0.1, 12.0.2, etc. I believe we (me or
some of my colleagues) can act as release co-ordinators, if that helps.
-jt
po 22. 6. 2020 v 12:26 odesílatel Neil C Smith <[email protected]>
napsal:
On Mon, 22 Jun 2020 at 11:10, Jaroslav Tulach <[email protected]>
wrote:
do we plan to provide patches to 12.0 version? E.g. 12.0.x versions with
only selected bugfixes? What's the process of getting a fix in? For
example
https://github.com/apache/netbeans/pull/2210 is something I'd like to
see
included.
Assuming we do what we've done previously, second PR on top of
release120 branch after that's gone in to master. May or may not
require changes - eg. different spec version for modules.
We also did a full source zip release for 11.2-u1, which I presume is
what you would need here?
OracleLabs is planning to update to 12.0 LTS, but the team would like to
understand how support for the LTS is going to work and for how long the
fixes are going to be produced?
We originally agreed until 13.0, so 12 months, for critical fixes. But ...
See the recent thread Laszlo initiated - maybe we still need to
clarify some things around release processes and what an LTS means?
Given I included LTS in the original release schedule proposal, with
some concerns about the need, our capacity, and our lack of a clear
definition of what it means, I'd be interested in what OracleLabs
requirements of an LTS are?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
