Hi Rory, thank you very much for this heads up! Opening up the build-and-test infrastructure and the commercial components sounds like an amazing development. Some early thoughts. The methodology of faster release cycles is very welcome, yet the proposed versioning I saw mentioned on twitter to be "year based" is a bit puzzling: in our experience it's nice to be able to clearly differentiate a non-backwards compatible version from a backwards compatible version, and yet be in control of when an "incompatibility event" happens: that can't be time boxed as generally we all try to avoid it but sometimes innovation requires to. I guess we could agree that technically no changed software is fully backwards compatible from all perspectives, but people are aware of this and yet benefit from knowing the maintainer's intent. This seems to map to the "long term support" editions but then those LTS versions only become the "version" in people's perspective. Specifically my concern would be that different versions would be perceived as a significant migration risk even though such an update might be relatively much simpler than others. It's possible that in practice Java 10 already had some breaking changes planned so this concern wouldn't apply right now, but with such numbering you'll never be able to benefit from it even in future releases. I'd welcome faster innovation cycles but libraries like Hibernate can't drop support for JVMs still largely in use, so unless people get comfortable in adopting new JVM versions by removing any such mental barriers we won't be able to adopt new versions as fast as we'd all like. On the other hand if the suggestion is that libraries should generally target "long term support" platforms, then it becomes painfully slow: as in other OSS projects - like Fedora - practical needs dictate that you at least support the two latest platforms so that would force us to support 6+ years old JVMs and slow innovation down rather than speeding it up. (Fedora supports the last two releases but a new release appears every 6 months). We'll think about this in the team and see if it's worth sharing some more thoughts on the OpenJDK mailing list. Regards, Sanne On 7 September 2017 at 10:35, Rory O'Donnell <rory.odonnell(a)oracle.com&gt; wrote: > Hi Sanne, > > Oracle is proposing a rapid release model for Java SE going-forward. > > The high points are highlighted below, details of the changes can be > found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2]. > > Under the proposed release model, after JDK 9, we will adopt a strict, > time-based model with a new major release every six months, update > releases every quarter, and a long-term support release every three years. > > The new JDK Project will run a bit differently than the past "JDK $N" > Projects: > > - The main development line will always be open but fixes, enhancements, > and features will be merged only when they're nearly finished. The main > line will be Feature Complete [3] at all times. > > - We'll continue to use the JEP Process [4] for new features and other > significant changes. The bar to target a JEP to a specific release will, > however, be higher since the work must be Feature Complete in order to > go in. Owners of large or risky features will be strongly encouraged to > split such features up into smaller and safer parts, to integrate > earlier in the release cycle, and to publish separate lines of > early-access builds prior to integration. > > The JDK Updates Project will run in much the same way as the past "JDK > $N" Updates Projects, though update releases will be strictly limited to > fixes of security issues, regressions, and bugs in newer features. > > Related to this proposal, we intend to make a few changes in what we do: > > - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to > make it easier for developers to deploy Java applications to cloud > environments. We'll initially publish OpenJDK builds for Linux/x64, > followed later by builds for macOS/x64 and Windows/x64. > > - We'll continue to ship proprietary "Oracle JDK" builds, which include > "commercial features" [6] such as Java Flight Recorder and Mission > Control [7], under a click-through binary-code license [8]. Oracle will > continue to offer paid support for these builds. > > - After JDK 9 we'll open-source the commercial features in order to make > the OpenJDK builds more attractive to developers and to reduce the > differences between those builds and the Oracle JDK. This will take some > time, but the ultimate goal is to make OpenJDK and Oracle JDK builds > completely interchangeable. > > - Finally, for the long term we'll work with other OpenJDK contributors > to establish an open build-and-test infrastructure. This will make it > easier to publish early-access builds for features in development, and > eventually make it possible for the OpenJDK Community itself to publish > authoritative builds of the JDK. > > Questions , comments, feedback to OpenJDK discuss mailing list [2] > > Rgds,Rory > > [1]https://mreinhold.org/blog/forward-faster > [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html > [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > [4]http://openjdk.java.net/jeps/0 > [5]http://openjdk.java.net/legal/gplv2+ce.html > [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html > [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/i... > [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev