Page History

Release Process

The release cycle for release 8u<n> starts its initial stage in the jdk8u-dev 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 general availability (GA), an update release enters Rampdown. From that point onwards, the update release is stabilized by only accepting very select fixes in jdk8u, such as regressions, high priority issues and test fixes. Tagging again takes place on a weekly basis - when changes 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 announced for jdk8u, allowing the maintainers of the security changes (currently Red Hat) to integrate these into the repository and perform final testing of the collected fixes in a secure, internal environment. On release day, the final batch of changes will be 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

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
Weekly During Initial Stage	Merge jdk8u-dev to jdk8u: 1. On jdk8u-dev repository: `git pull` `git tag -a jdk8u<n>-b<build>` 2. On jdk8u repository: `git pull <jdk8u-dev repository location>` ... 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 with jdk8u<release after n>-b00: `git pull` `git tag -a jdk8u<release after n>-b00` `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=39501 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=39500 that shows eligible fixes for pushing Add version openjdk8u<release after n> to fixVersion
Weekly During Rampdown	Tag jdk8u and merge back to jdk8u-dev: 1. On jdk8u: `git pull -u` `git tag -a` `jdk8u<n>-b<build>` ... after successful testing ... `git push` 2. On jdk8u-dev: `git pull` `git pull <jdk8u repository location>` `<resolve any merge issues>` `git commit -m "Merge"` ... 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>-ga tag have been pushed	Sync ga tag back to jdk8u-dev: 1. On jdk8u: `git pull` 2. On jdk8u-dev: `git pull` `git pull <jdk8u repository location>` `<resolve any merge issues>` `git commit -m "Merge"` ... after successful build ... `git push`
	Request new hgupdater setting for jdk8u codeline to honor version openjdk8u<release after n> on push

Rule 0

This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk8u-dev mailing list prior to approval to allow for public feedback. Project Lead is Sean Coffey

Rule 1

All changes that are not specific to JDK 8 Update MUST go into the JDK Project first. As a special exception, a change MAY go into JDK 8 Update if it is at the same time also proposed for inclusion into the JDK Project.

Rule 2

The always open mainline JDK 8 Update forest is maintained by the Project Lead. Exceptions to that are e.g. specific release repositories, where the Project Lead MAY delegate that authority.

Rule 3

Changes submitted for a JDK 8 Update forest MUST go through code review, and MUST be approved by the maintainer for that forest. The maintainer of a forest MAY delegate that authority, allowing for approvals to happen in a more finely granular fashion - per repository, for example.

If the change is an enhancement, then a separate enhancement backport requestMUST be approved by the maintainer for that forest prior to the change being submitted for code review and final maintainer approval.

Rule 4

Maintainer approvals for public JDK 8 Update forests MUST take place on the jdk8u-dev@openjdk.java.net mailing list. Code reviews SHOULD take place on that list - if they take place somewhere else, as part of the approval request a URL for the public code review MUST be provided.

Rule 5

A maintainer for a forest MAY pre-approve changes undergoing code review in JDK Project for commit to their forest in JDK 8 Update.

Rule 6

A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest.

Rule 7

A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest.

Rule 8

For changes submitted for inclusion into a public JDK 8 Update forest, the corresponding bug tracker entry SHOULD be publicly visible.

Rule 9

...

Page tree

Versions Compared

Old Version 1

New Version Current

Key