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

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