Page History

Release Process

Right after the update release 8u<m(=release before n)> was branched from mercurial forest jdk8u-dev to jdk8u, the The release cycle for release 8u<n> starts . As the very first step, its initial stage in the jdk8u-dev repository will be tagged with jdk11.0.<n>+0. One of the first changes should be to bump the version, e.g. something similar to JDK-8219710. At about 6 weeks repository as soon as the previous release enters its second stage and is confined to the jdk8u repository. The starting point is tagged with jdk8u<n>-b00. Once the previous release has happened, jdk8u-dev begins a cycle of being tagged on a weekly basis - when new changesets have been pushed - and the latest tag is promoted from jdk8u-dev to jdk8u. The tags have the format of jdk8u<n>-b<build>, where <n> is the placeholder for the update release and <build> is the monotonically increasing double digit build number.

About 6 weeks before its release, or before its general availability (GA), an update release enters ramp down phase 2 (RDP2) and the current state of jdk11u-dev will be transported to jdk11uenters Rampdown. From that point onwards, the update release is stabilized by only accepting very select fixes in jdk11u. Eligible candidates are fixes that Oracle has brought to their correspondent JDK11 update release, fixes for jdk8u, such as regressions, high priority issues or and test fixes. Builds from jdk11u will be tagged Tagging again takes place on a weekly basis , - when new changesets have been pushed. The tags will have the format of jdk11.0.<n>+<build>, where <n> is the placeholder for the update release and <build> is the monotonically increasing build number. Each tag that gets set in jdk11u will be integrated back to jdk11u-dev in a timely manner. At about 2 weeks before GAchanges have occurred - but this time, it occurs in the opposite direction, with jdk8u changes being integrated back to jdk8u-dev. At the end of the month prior to the release month, a complete freeze will be anounced for jdk11uannounced for jdk8u, allowing the maintainers of the security changes (currently Red Hat) to integrate and test these into the repository and perform final testing of the collected fixes in a secure, internal environment. At the On release day, these the final batch of changes will be merged into jdk11u pushed to jdk8u and the final tags jdk11.0.<n>+<build> and jdk11.0.<n>tags jdk8u<n>-b<build> and jdk8u<n>-ga will be set. To complete the process, jdk8u changes are integrated back into jdk8u-dev.

Release

...

Engineers Checklist

When	What
Very early, e.g. 6 months before GA	Publish timeline on Wiki page
	Create release specific JBS filters, e.g. for monitoring backports to keep in sync with Oracle
~ 6 weeks before GAWeekly During Initial Stage	Merge jdk11ujdk8u-dev to jdk11ujdk8u: 1. On jdk11ujdk8u-dev repository: `git pull` `git tag -a jdk8u<n>-b<build>hg pull -u` 2. On jdk11u jdk8u repository: `hg git pull <jdk8u-u` `hg pull <jdk11u-dev repository location>hg merge` `hg commit -m "Merge"` `hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u` ... after successful testing ... `git push`
Rampdown	Announce (short) freeze of jdk11ujdk8u-dev for preparation of release 11.0.<n+1>on 8u<release after n>on the mailing list
	Set status of jdk11ujdk8u-dev to "closed" and jdk11u jdk8u to "accepting fixes for 11.0.<n>8u<n>" in Wiki
	Tag jdk11ujdk8u-dev with jdk11.0.<n+1>+0jdk8u<release after n>-b00: `hg git pull -u` `hg tag jdk-11.0.<n+1>+0` `git tag -a jdk8u<release after n>-b00` `git push` `hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev`
	Request new JBS version 11.0.<n+1> openjdk8u<release after n> and change of hgupdater settings for jdk11ujdk8u-dev codeline to honor new version on push
	Update JBS filter https://bugs.openjdk.java.net/issues/?filter=3655839501 that shows eligible critical fixes Add version 11.0.<n> openjdk8u<n> to fixVersion
	Create patch to bump the version in jdk11u-dev to 11.0.<n+1>, look at JDK-8219710 for an example.	Await confirmation for hgupdater change, then update Wiki to set status of jdk11ujdk8u-dev to "accepting changes for 11.0.<n+1>8u<release after n>", announce opening of jdk11ujdk8u-dev for new release on mailing list
	Update https://bugs.openjdk.java.net/issues/?filter=3641239500 that shows eligible fixes for pushing Add version 11.0.<n+1> to fixVersionopenjdk8u<release after n> to fixVersion
Weekly During Rampdown	Tag jdk8u	~6 weeks before GA until ~2 weeks before GA in a weekly rythm initial tag (b1) to be done right after merge from jdk11u-dev	Tag jdk11u and merge back to jdk11ujdk8u-dev: 1. On jdk11u repositoryjdk8u: `hg git pull -u` `hg tag` `jdk-11.0.<n>+<b>` `git tag -a` `jdk8u<n>-b<build>` ... after successful testing ... `git pushhg push` `ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u` 2. On jdk11ujdk8u-dev repository: `hg git pull -u` `hg git pull <jdk11u-dev <jdk8u repository location> -r <change id of tag change>` `hg merge` `<resolve any merge issues>` `git hg commit -m "Merge"` `hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev` ... after successful build ... `git push`
Freeze	Announce freeze of jdk8u for preparation of release 8u<n> on the mailing list. No more changes will be added to the public tree before release day. Security changes will be prepared in private.
	Set status of jdk8u to "closed" on the Wiki
Release day, once security changes and jdk8u<n>- release day, when security changes and jdk-11.0.<n>-ga tag have been pushed	Sync ga tag back to jdk1ujdk8u-dev: 1. On jdk11u repositoryjdk8u: `hg git pull -u` 2. On jdk11ujdk8u-dev repository: `hg git pull -u` `hg git pull <jdk11u-dev <jdk8u repository location> -r <change id of ga tag>` `hg merge` `<resolve any merge issues>` `git hg commit -m "Merge"` `hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev` Set status of jdk11u to "closed" ... after successful build ... `git push`
	Request new hgupdater setting for jdk11u jdk8u codeline to honor version 11.0.<n+1> openjdk8u<release after n> on push

Page tree

Versions Compared

Old Version 6

New Version Current

Key

Release Process

Release

Engineers Checklist