Accelerating the JDK release cadence
Andrew Hughes
gnu.andrew at redhat.com
Wed Sep 6 16:58:15 UTC 2017
On 6 September 2017 at 16:39, Mario Torre <neugens at redhat.com> wrote:
snip...
> involved people to really pushing to the openness!
>
> I'm curious about the model and how it will practically work out, i.e
> "a new feature release every six months, update releases every
> quarter, and a long-term support release every three years". Does it
> means that the long-term support is the equivalent of today
> jdk7jdk8/jdk9 etc.. while the other will be basically just development
> version in between with various degree of stability? Or is it the goal
> that every version will be production ready?
>
My interpretation of this was that it would be something like the Firefox
model. As Mark's blog states in more detail, the idea is for all releases
to be production ready and, indeed, for the development mainline to be
more stable in general, so big features would only go in when they
are ready to go out (implying they need to be tested heavily elsewhere)
So I see it more as distros like Fedora would pick up every feature
release, while something like RHEL would use the long-term
support release. I presume update releases would be made available
for both; basically the equivalent of the current security releases
on the same cycle. So, October 2018 & January 2019 would see
just the security update for the long-term support release, 18.9, but
April 2019 would see security updates for both 18.9 and 19.3, the next
feature release after the long-term release (assuming updates stick
to Oracle's product-wide quarterly update cycle).
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the discuss
mailing list