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.
Changes that get approved (via the jdk8u-fix-yes label) have to be pushed to the jdk8u-dev repository forest. Those changes will then reach the next JDK 8 update release that has not yet reached RDP2 phase.
If a requester thinks that a fix should reach the current JDK update release when it is already in RDP2 phase, then he needs to explicitly state this in the "Fix Request" comment and provide some reasoning for that. The approver will then decide and give the according directions. If and only if the approver explicitly approves a fix for RDP2, it may be pushed to the jdk8u repository forest. Eligible candidates for RDP2 exceptions would be fixes that Oracle has brought to their correspondent JDK8u 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 closed testing.
JDK 8u212 timeline
- Mid March 2019 RDP2
- Early April 2019 RC phase (code freeze)
- Mid April 2019 GA
JDK 8u222 timeline
- March 2019 jdk11ujdk8u-dev forest open
- Late May 2019 RDP2
- Early July 2019 RC phase (code freeze)
- Mid July 2019 GA
JDK 8u232 timeline
- June 2019 jdk11ujdk8u-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