JDK 9 Release Candidate process proposal

mark.reinhold at oracle.com mark.reinhold at oracle.com
Sun Jun 18 19:58:46 UTC 2017

Per the JDK 9 schedule [1] we are now approaching the Initial Release
Candidate milestone.  After this week's build, which will be promoted
on Thursday (2017/6/22), we should fix only those bugs that are truly
showstoppers to the success of the release.  I propose that we further
tighten the goals previously adopted for RDP 2:

  - Fix all P1 bugs that are new in JDK 9 and critical to the success
    of this release;

  - Decommit from fixing any P1 bugs that are not new in JDK 9 and are
    not critical to this release, but were previously targeted to this
    release; and

  - Explicitly defer any P1 bugs that are new in JDK 9 but are either
    not critical to this release or cannot, for good reason, be fixed
    in this release.

All P2-P5 bugs must be left to future releases, regardless of whether
they are in product code, tests, or documentation.  There is no need
to defer unfixed P2-P5 bugs explicitly.

The current list of RC bugs can be found here: http://j.mp/jdk9-rc .
If you're responsible for a bug on this list then, just as in RDP 2,
you can take one of the following actions:

  - Fix the bug and then request approval to integrate the fix, using
    the existing fix-request process [2]; or

  - If the bug is not new in JDK 9 (check the "Affects Version" field)
    then you can remove it from the list by clearing the "Fix Version"
    field, or by setting that field to "tbd_major" if the fix would only
    be suitable for a major release, or by setting that field to
    "tbd_minor" if the fix would be suitable for any release [3]; or

  - If the bug is new in JDK 9 but is not critical or cannot be fixed in
    time then you can request that the bug be deferred explicitly from
    the release, using the deferral process that we adopted earlier for
    RDP 1 [4].

In any case, do not change the priority of a bug in order to remove it
from the list.  The priority of a bug should reflect the importance of
fixing it independent of any particular release, as has been standard
practice for the JDK for many years.

The overall feature set has been frozen for some time now.  No further
enhancements, no matter how small and low-risk, will be approved after
the Initial Release Candidate build.

JDK 9 Committers are invited to comment on this process proposal.  If
no serious objections are raised in one week's time, by 08:00 UTC next
Monday, 26 June, then this is the process that we'll use.

- Mark

[1] http://openjdk.java.net/projects/jdk9/
[2] http://openjdk.java.net/projects/jdk9/fix-request-process
[3] You can also set the "Fix Version" field to a specific future
    release, but bear in mind that by doing so you create the need
    to review the bug yet again during that future release.
[4] http://openjdk.java.net/projects/jdk9/bug-deferral-process

More information about the jdk9-dev mailing list