Re: [hibernate-dev] Should we support out of date non-LTS Java versions?
Hi,
I think we should make it clear that only LTS JVMs are actually supported,
and non-LTS JVMs are only supported on a "best effort" basis, with some
focus on the very latest non-LTS JVM.
I doubt we have the appropriate resources to do anything more than that.
To be more specific, I would see things this way:
- We may remove compatibility with an LTS JVM in a major release.
- We will always, systematically remove compatibility with older non-LTS
JVMs in every major or minor release, except the very latest JVM (which
might be a non-LTS): we don't even test them anymore, and we don't list
them as compatible on our website.
- We may remove compatibility with a non-LTS JVM in a micro release, but
we try not to actively do it...
Specifically in the case of your dependency removal in a micro: that
doesn't seem very useful to users, and doesn't solve a bug, so I wouldn't
do it. Also, changing dependencies in a micro doesn't feel quite right: I'd
expect micros to be drop-in replacements, and I can imagine adding/removing
dependencies to cause trouble in build tools/build configuration.
But I wouldn't make it a hard rule, either: we may be forced to do it one
day because of a bug, and such a small break is still better than a bug.
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Hi all,
I just tested if we still need the dependency to
'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM /
master, as I was suspecting the original reasons to add it might be
out of date.
I guessed almost right, as it turns out we don't need this dependency
for Java 11, nor it was ever needed for Java 8 either: it was
introduced to solve a specific Java 9 compatibility issue.
I verified it's still needed for Java 9 compatibility. Personally that
makes me think I'd rather remove the dependency, people should no
longer use Java 9;
Java 9 has been "out of support" since a while now: I expect people to
either be on the latest stable release Java 11 - or on the previous
stable release aka Java 8 (others might be toying with 12 and/or 13
but that's not relevant).
Clearly since we have no more 5.x minor releases planned, I'm thinking
of dropping a JVM version in a micro (!) - but considering this is an
unsupported non-LTS JVM I'm not considering this to be an outrageous
idea as we'd normally treat such a suggestion.
Please don't take this as nitpicking about removing a single
dependecy: that's easy enough for people to ignore and workaround by
re-adding it explicitly; it's more important to focus on us creating a
clear policy for the future.
Can we establish how we'll treat support for any other future
non-Long-Term-Support JVM version?
Next time we might have a more tricky issue, and I think we should
make our intentions and policy clear so to have freedom to drop
support for experimental Java releases as we see fit, provided they
are out of date.
I couldn't test JDK 10 - but that doesn't matter as the details of
this specific issue are irrelevant to the main point of agreeing on a
general policy.
Comments?
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev