Proposed schedule for JDK 18.3

Andrew Hughes gnu.andrew at
Mon Oct 16 15:09:53 UTC 2017

On 13 October 2017 at 09:25, Seán Coffey <sean.coffey at> wrote:
>> Given the shorter stabilization period there likely won't be time for
>> every bug fix to percolate from the main line into the release repo, so
>> I expect that some (most?) fixes will go directly into the release repo.
>> We'll try to automate merges of such fixes back into the main line, as
>> we did for JDK 9.
> I'm not sure if this is the best model to adopt. The JDK 8 Updates Project
> has been
> using a critical-request model for some time now. It works well. Before
> accepting a
> patch into an upcoming production release (stabilization forest), we know
> that the
> patch has been soaked in the mainline where EA binaries are available and
> where
> more test infrastructure/cycles might also be available.
> Pulling a patch from the mainline also reduces concerns about avoiding a
> possible
> regression in a future release if a patch gets accidentally dropped or
> doesn't get ported
> in time for the next JDK release (which would be less than 6 months away)
> Given the regular 6 monthly release cycle, I'm hoping the bar will be real
> high for
> acceptance of such patches into a release post ramp-down.

I agree that's a better model.

However, what I wouldn't like to see copied from 8u is that these forked
release branches aren't public e.g. we can't see 8u152 until it's pushed
to the 8u tree.

> Regards,
> Sean.

Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (

Web Site:
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

More information about the jdk-dev mailing list