Summary

Define the process by which Contributors in the OpenJDK Community producetime-based, rapid-cadence JDK feature releases.

Quick reference

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

	Candidates	Fix	Drop	Defer	Enhance?
RDP 1	Current P1–P3 Targeted P1–P3	Current P1–P3 Targeted P1–P3 if time P1–P5 doc/test changes	All P4–P5 Targeted P1–P3	Current P1–P2,  with approval	With approval
RDP 2	Current P1–P2 Targeted P1–P2	Current P1–P2,  withapproval P1–P5 doc/test changes	All P3–P5 Targeted P1–P2	Current P1–P2,  with approval	With approval
RC	Current P1 Targeted P1	Current P1,  withapproval	All P2–P5 Targeted P1	Current P1,  with approval	No

Overview

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

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

• Rampdown Phase One(RDP 1)[ candidate bugs ]
• Rampdown Phase Two(RDP 2)[ candidate bugs ]
• Release-Candidate Phase(RC)[ candidate bugs ]

The durations of the phases can vary from release to release, but as anexample the phases forJDK 11 were 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, andsubjects actions taken on those bugs to an increasingly-higher level ofreview. This ensures that, in each phase, we fix the bugs that need tobe fixed at that time. It also ensures that we understand why we’re notfixing some bugs that perhaps ought to be fixed but, for good reason, arebetter left to a future release. The phases thus make use of twoapproval processes, also described below:

• Bug-Deferral Process[ pending requests ]
• Fix-Request Process[ pending requests ]

The overall feature set is frozen at RDP 1. No furtherJEPs willbe targeted to the release after that point.

Late, low-risk enhancements that add small bits of missing functionalityor improve usability are permitted with approval in RDP 1 andRDP 2, especially when justified by developer feedback orJCP EG support, but the bar is very high in RDP 1 andextraordinarily high in RDP 2. You can request approval for a lateenhancement via a third process:

• Late-Enhancement Request Process[ pending requests ]

Candidate bugs

Each phase is driven by a list ofcandidate bugs. The candidate bugsin each phase are at or above that phase’spriority threshold, whichstarts at P3 for RDP 1 and then increases to P2 for RDP 2 andP1 for RC. Each candidate bug is either

• Acurrent bug, discovered in anearly-access build of JDK $N and reported against that releasevia theAffects Version field, or

• Atargeted bug, reported against some pastrelease but targeted, via theFix Version field, to JDK $N.

Acritical bug is a current bug whosepriority 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. Tosummarize:

	Priority	Critical	Query
RDP 1	≥ P3	≥ P2	openjdk.org/s/jdk-rdp-1
RDP 2	≥ P2	≥ P2	openjdk.org/s/jdk-rdp-2
RC	= P1	= P1	openjdk.org/s/jdk-rc

Actions in a phase

In each phase we aim tofix,drop, ordefer each candidate bug.If you’re responsible for a candidate bug then please take one of thefollowing actions:

• Fix If the bug is current thendevelop a fix and either integrate it when ready (in RDP 1) orrequest approval to integrate it via thefix-request process(RDP 2 and RC). In RDP 1, if the bug is targeted and iftime permits, develop and integrate a fix when ready.

• Drop If the bug is targeted, butnot critical, then drop it from the release by either

  • Clearing theFix Version field, or

  • Setting theFix Version field to $N + 1 if you’rereasonably confident that you’ll fix the bug in the next release,or

  • Setting theFix Version field totbd if you’ve determinedthat the fix will not make the next release but might make somelater release.

• Defer If the bug is critical butcannot be fixed in time, or is too risky to fix, then requestapproval to defer the bug from the release via thebug-deferralprocess.

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

Non-candidate bugs

If you’re responsible for a non-candidate bug that’s targeted toJDK $N via theFix Version field then please drop it by eitherclearing that field, or setting it to $N + 1, or setting it totbd, as above. There’s no need to defer such bugs via the deferralprocess.

Test and documentation bugs and enhancements

Bugs and enhancements of any priority that only affect tests, ortest-problem lists, or documentation may be addressed in RDP 1 andRDP 2. You don’t need to request approval for such a change inorder to integrate it, but please do make sure that the issue has anoreg-self ornoreg-doc label, as appropriate.

Integrating fixes and enhancements

Most fixes and enhancements intended for the stabilization release willalso be applicable to the main-line release. To make such a change inthe stabilization release:

1. Target the relevant JBS issue to the main-line release, immediatelycreate a backport of that issue, and target the backport to thestabilization release.

2. Create a PR to integrate your change into the main-line repository.

3. After you obtain any necessary approvals, backport the main-line PRto the stabilization repository via the Skara/backport commandor, if necessary, by manually opening a backport PR with the titleBackport $HASH, where$HASH is the original commit hash.

All such backports require re-review, even if they areclean, in orderto ensure stability. (The Developers’ Guide contains more information onworking with backports.)

Some fixes and enhancements will be specific to the stabilization releaseand not applicable to the main-line release. Integrate such changesdirectly into the stabilization repository.

In order to make sure that no backports are missed, prior to theRDP2 andRC phases JDK Contributors will be reminded to reviewbug fixes that have been integrated into the main-line repository but notbackported to the stabilization repository. These JBS queries can beuseful:

• Bug fixes not backported from the main line
• My bug fixes not backported from the main line

Bug-Deferral Process

This process applies fromRDP 1 until the end of the release.

Requesting a deferral

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

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

Reviewing deferral requests

TheArea Leads, relevant Group Leads, and the JDK Project Leadwill review thepending deferralrequests on a regular basis,several times per week. One of them will take one of the followingactions:

• Approve the request by adding the labeljdk$N-defer-yes. (There isno need to add a comment recording this approval.)

• Reject the request by adding the labeljdk$N-defer-no, along with acomment describing the reason for this action.

• Request more information by adding the labeljdk$N-defer-nmi(“nmi” = “needs more information”), along with a comment describingwhat information is requested.

In any case,do not remove thejdk$N-defer-request label.

JBS query for pending requests:openjdk.org/s/jdk-defer-pending

Responding to actions taken on your deferral request

• If you’re asked to provide more information for a deferral requestthen please do so in a new comment in the issue, and then remove thejdk$N-defer-nmi label so that reviewers see that it’s ready forre-review.

• If your request is approved then no further action on your part isrequired.

Fix-Request Process

This process applies fromRDP 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 advicefrom a Group or Area Lead, on an appropriate mailing list, to make surethat fixing the bug in this release is actually a reasonable idea.

When you are confident in your fix then update the relevant JBS issue toadd a comment whose first line is “Fix Request”. (You need not wait forthe fix itself to be approved for integration by appropriate Reviewers.)In that comment briefly describe why it’s important to fix this bug,explain the nature of the fix, estimate its risk, describe its testcoverage, and indicate who has reviewed it. If you have a pull requestor 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 labeljdk$N-fix-request to the issue, substituting the actual release versionnumber for$N.

Always add the comment and label to the main-line JBS issue; do not addthem to a backport issue.

Reviewing fix requests

TheArea Leads, relevant Group Leads, and the JDK Project Leadwill review thepending fixrequests on a regular basis, atleast weekly to start and more frequently as we approach the GA date.In case of an urgent situation you are welcome to contact an appropriatereviewer directly in order to solicit a prompt review.

A reviewer will take one of the following actions:

• Approve the request by adding the labeljdk$N-fix-yes, along with acomment recording their approval whose first line is “Fix requestapproved”.

• Reject the request by adding the labeljdk$N-fix-no, along with acomment describing the reason for this action whose first line is“Fix request rejected”.

• Request more information by adding the labeljdk$N-fix-nmi (“nmi”= “needs more information”), along with a comment describing whatinformation is requested whose first line is “Fix request NMI”.

In any case,do not remove the originaljdk$N-fix-request label.

JBS query for pending fix requests:openjdk.org/s/jdk-fix-pending

Responding to actions taken on your fix request

• If you’re asked to provide more information for a fix request thenplease do so in a new comment in the issue, and then remove thejdk$N-fix-nmi label so that reviewers see that it’s ready forre-review.

• If your request is approved then proceed to complete the fix andintegrate it.

• If your request is rejected then you may appeal that decision to theProject Lead.

In any case,do not remove the originaljdk$N-fix-request label.

Late-Enhancement Request Process

This process applies fromRDP 1 until the end ofRDP 2.

Requesting approval for a late enhancement

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

Always add the comment and label to the main-line JBS issue; do not addthem to a backport issue.

Enhancements to tests and documentation during RDP 1 and RDP 2do not require approval, as long as the relevant issues are identifiedwith anoreg-self ornoreg-doc label, as appropriate.

Reviewing enhancement requests

The JDK Project Lead or a delegate, in case of absence, will review thepending enhancementrequests on a regularbasis, several times per week. They will take one of the followingactions:

• Approve the request by adding the labeljdk$N-enhancement-yes,along with a comment recording their approval whose first line is“Late enhancement approved”.

• Reject the request by adding the labeljdk$N-enhancement-no, alongwith a comment describing the reason for this action whose first lineis “Late enhancement rejected”.

• Request more information by adding the labeljdk$N-enhancement-nmi(“nmi” = “needs more information”), along with a comment describingwhat information is requested.

In any case,do not remove thejdk$N-enhancement-request label.

JBS query for pending requests:openjdk.org/s/jdk-enhancement-pending

Responding to actions taken on your enhancement request

• If you’re asked to provide more information for an enhancementrequest then please do so in a new comment in the issue, and thenremove thejdk$N-enhancement-nmi label so that reviewers see thatit’s ready for re-review.

• If your request is approved then update the issue’s due date to theexpected completion date.

History

• 2023/6/1 — Revised to describe the stabilize-via-backports idiomadopted in JDK 21(proposal).

• 2023/12/20 — Revised the integration instructions to advise theimmediate creation of backport issues in order to avoid losing trackof candidate bugs(proposal).

• 2024/12/1 — Replaced brokenj.mp links withopenjdk.org/s links.