[hibernate-dev] Should we support out of date non-LTS Java versions?

[Sanne Grinovero]

Looks like we all agree on these guidelines, and since a week is
passed I assume everyone else is fine too :)
and thanks Yoann for updating the compatibility notes on the website!

One first consequence is that the JDK9 and JDK10 jobs on CI are being
abandoned; apparently they already aren't run regularly. We could
eventually remove them, but I'll leave them for a while as they are
still useful to diagnose some stuff occasionally.


Sanne


On Wed, 13 Feb 2019 at 15:13, Steve Ebersole <steve at hibernate.org> wrote:
>
> +1 to everything Yoann said.
>
>
> On Wed, Feb 13, 2019, 5:42 AM Yoann Rodiere <yoann at hibernate.org> wrote:
>
> > 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 at hibernate.org
> >
> >
> > On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero <sanne at 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev