JEP 3: JDK Release Process

OwnerMark Reinhold
TypeProcess
ScopeJDK
StatusActive
Discussionjdk dash dev at openjdk dot java dot net
Created2018/06/19 16:58
Updated2022/06/09 17:45
Issue8205352

Summary

Define the process by which contributors in the OpenJDK Community produce time-based, rapid-cadence JDK feature releases.

Quick reference

This table is provided here for easy access; the terminology it uses is defined below.

CandidatesFixDropDeferEnhance?
RDP 1 Current P1–P3
Targeted P1–P3		 Current P1–P3
Targeted P1–P3 if time
P1–P5 doc/test bugs		 All P4–P5
Targeted P1–P3		 Current P1–P2,
 with approval 		With
approval
RDP 2 Current P1–P2
Targeted P1–P2		 Current P1–P2,
 with approval
P1–P5 doc/test bugs		 All P3–P5
Targeted P1–P2		 Current P1–P2,
 with approval 		With
approval
RC Current P1
Targeted P1		 Current P1,
 with approval 		All P2–P5
Targeted P1		 Current P1,
 with approval 		No

Overview

Ongoing JDK development takes place in the main-line repository of the JDK Project, github.com/openjdk/jdk. This repository is always open for new work.

Every six months, in June and December, we initiate the release cycle for the next JDK feature release, hereinafter referred to as JDK $N. We fork the main-line repository into a stabilization repository, jdk/jdk$N, and use that repository for the remaining work needed to stabilize the release. That work proceeds over the next three months in three phases, described below:

The durations of the phases can vary from release to release, but as an example the phases for JDK 11 are four weeks for RDP 1, three weeks for RDP 2, and five weeks for RC.

Each successive phase narrows the set of bugs that we examine, and subjects actions taken on those bugs to an increasingly-higher level of review. This ensures that, in each phase, we fix the bugs that need to be fixed at that time. It also ensures that we understand why we’re not fixing some bugs that perhaps ought to be fixed but, for good reason, are better left to a future release. The phases thus make use of two approval processes, also described below:

The overall feature set is frozen at RDP 1. No further JEPs will be targeted to the release after that point.

Late, low-risk enhancements that add small bits of missing functionality or improve usability are permitted with approval in RDP 1 and RDP 2, especially when justified by developer feedback or JCP EG support, but the bar is very high in RDP 1 and extraordinarily high in RDP 2. You can request approval for a late enhancement via a third process:

Candidate bugs

Each phase is driven by a list of candidate bugs. The candidate bugs in each phase are at or above that phase’s priority threshold, which starts at P3 for RDP 1 and then increases to P2 for RDP 2 and P1 for RC. Each candidate bug is either

A critical bug is a current bug whose priority is either P1 or P2 (in RDP 1 and RDP 2) or P1 (in RC).

Queries for the candidate bugs for each phase are defined in JBS. To summarize:

PriorityCriticalQuery
RDP 1 ≥ P3 ≥ P2 j.mp/jdk-rdp-1
RDP 2 ≥ P2 ≥ P2 j.mp/jdk-rdp-2
RC = P1 = P1 j.mp/jdk-rc

Actions in a phase

In each phase we aim to fix, drop, or defer each candidate bug. If you’re responsible for a candidate bug then please take one of the following actions:

In any case, do not change the priority of a bug in order to remove it from the candidate 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.

Non-candidate bugs

If you’re responsible for a non-candidate bug that’s targeted to JDK $N via the Fix Version field then please drop it by either clearing that field, or setting it to $N + 1, or setting it to tbd, as above. There’s no need to defer such bugs via the deferral process.

Test and documentation bugs

Bugs of any priority whose fixes only affect tests, or test-problem lists, or documentation may be fixed in RDP 1 and RDP 2. If you have a fix for such a bug then you don’t need to request approval in order to integrate it, but please do make sure that the issue has a noreg-self or noreg-doc label, as appropriate.

Bug-Deferral Process

This process applies from RDP 1 until the end of the release.

Requesting a deferral

If you own a bug that will not be fixed in the current phase of development then you can request a deferral as follows: Update the JBS issue to add a comment whose first line is “Deferral Request”. In that comment briefly describe the reason for the deferral (e.g., insufficient time, complexity or risk of fix, etc.). Add the label jdk$N-defer-request to the issue, substituting the actual release version number for $N.

Deferrals will not be granted for TCK issues identified by the label tck-red-$N, except possibly when new TCK tests are involved. Deferrals are unlikely for bugs that prevent release testing.

Reviewing deferral requests

The Area Leads, relevant Group Leads, and the JDK Project Lead will review the pending deferral requests on a regular basis, several times per week. One of them will take one of the following actions:

JBS query for pending requests: j.mp/jdk-defer-pending

Responding to actions taken on your deferral request

Fix-Request Process

This process applies from RDP 2 until the end of the release.

Requesting approval to integrate a fix

Before you spend too much time on a fix for a P1 or P2 bug, seek advice from a Group or Area Lead, on an appropriate mailing list, to make sure that fixing the bug in this release is actually a reasonable idea.

When you are nearly ready with a fix then update the JBS issue to add a comment whose first line is “Fix Request”. In that comment briefly describe why it’s important to fix this bug, explain the nature of the fix, estimate its risk, describe its test coverage, and indicate who has reviewed it. If you have a webrev for the fix then include a link to that in the comment; otherwise, attach the patch for the fix to the JBS issue. Add the label jdk$N-fix-request to the issue, substituting the actual release version number for $N.

Reviewing fix requests

The Area Leads, relevant Group Leads, and the JDK Project Lead will review the pending fix requests on a regular basis, at least weekly to start and more frequently as we approach the GA date. In case of an urgent situation you are welcome to contact an appropriate reviewer directly in order to solicit a prompt review.

A reviewer will take one of the following actions:

JBS query for pending fix requests: j.mp/jdk-fix-pending

Responding to actions taken on your fix request

Late-Enhancement Request Process

This process applies from RDP 1 until the end of the RDP 2.

Requesting approval for a late enhancement

If you wish to integrate an enhancement in RDP 1 or RDP 2 then you can request approval as follows: Update the JBS issue to add a comment whose first line is “Late Enhancement Request”. In that comment describe the risk level, a brief justification that quotes actual developer feedback if possible, and your best estimate of the date by which you’ll integrate it. Add the label jdk$N-enhancement-request to the issue, substituting the actual release version number for $N.

Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate.

Reviewing enhancement requests

The JDK Project Lead or a delegate, in case of absence, will review the pending enhancement requests on a regular basis, several times per week. They will take one of the following actions:

JBS query for pending requests: j.mp/jdk-enhancement-pending

Responding to actions taken on your enhancement request