Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Update following git migration

Release Process

Right after the update release 8u<release before n> was branched from mercurial forest jdk8u-dev to jdk8u, the release The release cycle for release 8u<n> starts . As the very first step, its initial stage in the jdk8u-dev repository will be 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. At about . 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 general availability (GA), an update release enters ramp down phase 2 (RDP2) and the current state of jdk8u-dev will be transported to jdk8uenters Rampdown. From that point onwards, the update release is stabilized by only accepting very select fixes in jdk8u. Eligible candidates are fixes that Oracle has brought to their correspondent JDK8 update release, fixes for , such as regressions, high priority issues or and test fixes. Builds from jdk8u will be tagged Tagging again takes place on a weekly basis , - when new changesets have been pushed. The tags will have the format of jdk8u<n>-b<build>, where <n> is the placeholder for the update release and <build> is the monotonically increasing build number. Each tag that gets set in jdk8u will be changes have occurred - but this time, it occurs in the opposite direction, with jdk8u changes being integrated back to jdk8u-dev in a timely manner. At about 2 weeks before GA. At the end of the month prior to the release month, a complete freeze will be anounced announced 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 pushed to jdk8u and the final 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

WhenWhat
Very early, e.g. 6 months before GAPublish 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 jdk8u-dev to jdk8u:

1. On jdk8u-dev repository (and all its subrepositories):

hg git pull -u

git tag -a jdk8u<n>-b<build>

2. On jdk8u repository (and all its subrepositories):

hg git pull -u
hg pull <jdk8u-dev repository location>hg merge
hg commit -m "Merge"
hg push ssh://<userid>@hg.openjdk.java.net/jdk8u/jdk8u{/subrepository}

... after successful testing ...
git push

Rampdown

Announce (short) freeze of jdk8u-dev for preparation of release 8u<release after n>on the mailing list


Set status of jdk8u-dev to "closed" and jdk8u to "accepting fixes for 8u<n>" in Wiki

Tag jdk8u-dev (and all its subrepositories) with jdk8u<release after n>-b00:

hg git pull -u

hg git tag -a jdk8u<release after n>+-b00

hg push ssh://<userid>@hg.openjdk.java.net/jdk8u/jdk8u-dev{/subrepository}git push


Request new JBS version openjdk8u<release after n> and change of hgupdater settings for jdk8u-dev codeline to honor new version on push

Update JBS filter https://bugs.openjdk.java.net/issues/?filter=3656239501 that shows eligible critical fixes

Add version openjdk8u<n> to fixVersion


Await confirmation for hgupdater change, then update Wiki to set status of jdk8u-dev to

"accepting changes for 8u<release after n>", announce opening of jdk8u-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