Versions Compared

Old Version 2

changes.mady.by.user Christoph Langer

Saved on

compared with

New Version Current

changes.mady.by.user Severin Gehwolf

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: HG -> Git

Release Process

...

The Right after update release 11.0.<n-1> was branched from mercurial repository jdk11u-dev to jdk11u, the release cycle for release 11.0.<n> starts . As the very first step, its initial stage in the jdk11u-dev repository will be repository as soon as the previous release enters its second stage and is confined to the jdk11u repository. The starting point is tagged with jdk11.0.<n>+0. Once the previous release has happened, jdk11u-dev begins a cycle of being tagged on a weekly basis - when new changesets have been pushed - and the latest tag is promoted from jdk11u-dev to jdk11u. The tags  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.

About 6 weeks before its release, or One of the first changes should be to bump the version, e.g. something similar to JDK-8219710. At about 6 weeks 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 , 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 changes have occurred - but this time, it occurs in the opposite direction, with jdk11u changes being integrated back to jdk11u-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 jdk11u, 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 jdk11u and the final tags tags jdk11.0.<n>+<build> and jdk11.0.<n>-ga will be set. To complete the process, jdk11u changes are integrated back into jdk11u-dev.

Release Engineers Checklist (TODO: Update for Git)

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
Weekly During Initial Stage

Merge jdk11u-dev to jdk11u:

1. On jdk11u-dev repository:

hg pull -u

hg tag jdk-11.0.<n>+<build>

2. On jdk11u repository:

hg pull <jdk11u-dev repository location>

... after successful testing ...
hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u

Rampdown

Announce (short) freeze of jdk11u-dev for preparation of release 11.0.<n+1>on the mailing list


Set status of jdk11u-dev to "closed" and jdk11u to "accepting fixes for 11.0.<n>" in Wiki

Tag jdk11u-dev with jdk11.0.<n+1>+0:

hg pull -u

hg tag jdk-11.0.<n+1>+0

hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev


Request new JBS version 11.0.<n+1> and change of hgupdater settings for jdk11u-dev codeline to honor new version on push

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

Add version 11.0.<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 jdk11u-dev to

"accepting changes for 11.0.<n+1>", announce opening of jdk11u-dev for new release on mailing list


Update https://bugs.openjdk.java.net/issues/?filter=36412 that shows eligible fixes for pushing

Add version 11.0.<n+1> to fixVersion

Weekly During Rampdown

Tag jdk11u and merge back to jdk11u-dev:

1. On jdk11u repository:

hg pull -u

hg tag jdk-11.0.<n>+<b>

... after successful testing ...

hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u

2. On jdk11u-dev repository:

hg pull -u

hg pull <jdk11u repository location>

hg merge

hg commit -m "Merge"

... after successful build ...

hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev

Release day, once security changes

and jdk-11.0.<n>-ga tag have been pushed

Sync ga tag back to jdk11u-dev:

1. On jdk11u repository:

hg pull -u

2. On jdk11u-dev repository:

hg pull -u

hg pull <jdk11u repository location>

hg merge

hg commit -m "Merge"

hg push ssh://<userid>@hg.openjdk.java.net/jdk-updates/jdk11u-dev


Set status of jdk11u to "closed"

Request new hgupdater setting for jdk11u codeline to honor version 11.0.<n+1> on push

Fix Approvals

In general we follow the common rules for the jdk-updates project.

Push approval for a fix is requested by setting the jdk11u-fix-request label on the original bug. The maintainer will either approve by setting jdk11u-fix-yes or reject by setting jdk11u-fix-no. If and only if the fix gets approved, it may be pushed to the jdk11u-dev repository.

When a a JDK 11 update release is already in ramp down (jdk11u), a fix can be requested for consideration using the jdk11u-critical-request label. The maintainer may approve with jdk11u-critical-yes, defer to jdk11u-dev or reject. If and only the fix gets approved with jdk11u-critical-yes, it may be pushed to the jdk11u repository.

...