Hi Sanne, Please do share your thoughts on the OpenJDK mailing list.
Rgds,Rory On 07/09/2017 11:22, Sanne Grinovero wrote: > 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.odonn...@oracle.com> 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/index.html >> [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev