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