Welcome to JDK 8 Updates!
Processes and Infrastructure
As a preamble, the project lead has established general guidelines for working on jdk8u.
JDK 8 updates will be delivered in a quarterly cyle. Usually releases happen mid of January, April, July and October.
Update fixes are collected in the jdk8u-dev repository forest and update releases will be stabilized in the jdk8u repository forest. At the beginning of a release cycle, the jdk8u-dev repository forest will be tagged with jdk8u<x>-b00, where x is a placeholder for the update release (e.g. 212). At a certain point in time a release cycle enters ramp down phase 2 (RDP2) and jdk8u-dev will be transported to jdk8u. In jdk8u, stabilization is done by (only) accepting high priority or test fixes. jdk8u will be tagged on a weekly basis, when new changesets have been pushed. The tags will have the format of jdk8u<x>-b<nn>, where x is a placeholder for the update release and nn is the monotonically increasing double digit build number. At the release day, security changes that have been collected in a secure environment and tested internally at Red Hat will be merged into jdk8u and the final tags jdk8u<x>-b<nn> and jdk8u<x>-ga will be set. Each tag that gets set in jdk8u will be integrated back to jdk8u-dev in a timely manner.
Fix Approvals and Push Policy
In general we follow the common rules for the jdk-updates project.
Push approval for a fix is requested by setting the jdk8u-fix-request label on the original bug. The maintainer will either approve by setting jdk8u-fix-yes or reject by setting jdk8u-fix-no. If and only if the fix gets approved, it may be pushed to the jdk8u-dev repository forest. It will then reach the next JDK 8 update release that is not yet in RDP2 phase.
If a fix needs to be integrated into the current JDK 8 update release after RDP2, this can be requested via the jdk8u-critical-request label. The maintainer will approve with jdk8u-critical-yes or reject with jdk8u-critical-no. If and only the fix gets approved, it may be pushed to the jdk8u repository forest. Eligible candidates for approval after RDP2 would be fixes that Oracle has brought to their correspondent JDK8 update release, fixes for high priority issues and test fixes.
In the very last days before the release date, we won't accept any pushes to jdk8u in order to have the maintainers of the security fixes finish up their testing.
JDK 8u212 timeline
- Mid March 2019 RDP2
- Early April 2019 RC phase (code freeze)
- Mid April 2019 GA
JDK 8u222 timeline
- March 2019 jdk8u-dev forest open
- Late May 2019 RDP2
- Early July 2019 RC phase (code freeze)
- Mid July 2019 GA
JDK 8u232 timeline
- June 2019 jdk8u-dev forest open
- Late August 2019 RDP2
- Early October 2019 RC phase (code freeze)
- Mid October 2019 GA
Advanced JBS filters
The filters will only work for users that are logged into JBS.
Open Downports Oracle -> OpenJDK: https://bugs.openjdk.java.net/issues/?filter=36394
Additional commits in OpenJDK vs. Oracle: https://bugs.openjdk.java.net/issues/?filter=36458
Open Downports Oracle -> OpenJDK: https://bugs.openjdk.java.net/issues/?filter=36456
Additional commits in OpenJDK vs Oracle: https://bugs.openjdk.java.net/issues/?filter=36459
Open Downports Oracle -> OpenJDK: https://bugs.openjdk.java.net/issues/?filter=36513
Additional commits in OpenJDK vs Oracle: https://bugs.openjdk.java.net/issues/?filter=36512
The jdk8u-dev forest for ongoing development can be cloned using this command: hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev;cd jdk8u-dev;sh get_source.sh
The corresponding master forest jdk8u can be cloned using this command: hg clone http://hg.openjdk.java.net/jdk8u/jdk8u;cd jdk8u;sh get_source.sh
In addition, the source code for the last release, 8u202, is available by cloning the 8u master forest : http://hg.openjdk.java.net/jdk8u/jdk8u and using the 'jdk8u202-ga' mercurial tag.
Recent space activity