diff --git a/processes/release-process.md b/processes/release-process.md index 1223998ad6..45c02e8b58 100644 --- a/processes/release-process.md +++ b/processes/release-process.md @@ -133,130 +133,3 @@ versioned releases are available: - [{{repo}}](https://github.com/{{project.name}}/{{repo}}) {% endfor %} {% endfor %} - -## Release procedure - -This section describes how a release is done, and is mostly a checklist for -the person performing a versioned release. - -### Release window and freeze - -When a release is planned, decide on the timeframe of the release window in -which changes can still be made, and then make an announcement to the relevant -channels that a release is coming up and let people know of the release window -that you have decided. This is to give advance notice to contributors so that -they can prepare for the release and get features merged in before the release -is done. A decent timeframe for the release window is a month. - -The relevant channels for the announcement are: - -- [seL4 discourse][discourse] -- [seL4 announcement mailing list](https://lists.sel4.systems/postorius/lists/announce.sel4.systems/) -- [seL4 Mattermost](https://mattermost.trustworthy.systems/sel4-external/) - -Upon the end of the release window, announce the close of the window and the -start of the release freeze on the relevant channels. Pull requests should not -be merged during the release freeze except for those that fix issues and bugs -that occurred during the release window. Work towards getting the continuous -integration builds to be green while working on the next step. - -### Preparing changelogs - -Before preparing the changelogs for each project, review the changes of each -project since the last release and decide a new version number as according to -the [Version Numbers](#version-numbers) section. - -Clone the `seL4_release` repository from the [seL4 -organisation](https://github.com/seL4) (this is currently private and you will -need to ask for access). - -Move to the directory of the repository that you cloned and execute the -following while replacing the fields: - -```shell -./releaseit prerelease --config data/sel4_prerelease.yml --new-version= - -./releaseit prerelease --config data/capdl_prerelease.yml --new-version= --sel4-version= - -./releaseit prerelease --config data/camkes_prerelease.yml --new-version=camkes- --sel4-version= -``` - -These commands clone the projects in the `/tmp` directory of your machine and -apply two commits that add changes to the `CHANGES` and `VERSION` files. Note -that it also creates a `_release.md` file in each project directory. -You now need to add any extra changes since the last release that were not -already included in the `CHANGES` file for each project. To do so, run `git log` -with the relevant arguments to get the commits since the last release or go to -each project's GitHub page and filter the pull requests that were merged since -the last release. Go through each of the commits/pull requests and summarise -them in the `CHANGES` files. You do not need to add changes that are trivial. The -best way to think about this is: "If I'm a user of (seL4, CAmkES, capDL) will -it affect me? Do I need to know about it, e.g has the API changed? Are -variables renamed? New features? New licences? Removal of features?" etc. Make -sure to also update the `Upgrade Notes` section in each `CHANGES` file. - -Meanwhile, you can also work on making sure the continuous integration builds -are green while preparing the changelogs. Remember to also include any fixes and -changes from this process to the changelogs. - -### Verification - -Coordinate with the verification team to make a simultaneous release of the -verification repositories. If the proof builds are green, this should be a -relatively short process. If the proof builds are not green, the release must -wait until those are fixed. - -### Release - -Once the continuous integration builds are all green (make sure that the -verification builds are also green) and the changelogs are also done, amend the -commits that the release tool made with the updated `CHANGES` file in each -project, sign the commits off and submit pull requests for each project. Make -sure that the pull request **only** contains the two commits, one for updating -the `VERSION` and the `CHANGES` files to the latest version and one for -updating the `VERSION` file to add the `dev` suffix to the contents. - -The next step is to copy the contents of each project's `CHANGES` file to the -`_release.md` file in the same directory. Make sure that the top of -the `_release.md` file contains a `project: sel4`, `project: camkes`, -or `project: capdl` tag. Take all of the `_release.md` files and -rename them to the current release version and add them under the `_releases` -folder in the docsite's repository -[here](https://github.com/seL4/docs/tree/master/content_collections/_releases). -Submit a pull request for those changes as well. - -Get all pull requests (should be four, one for each project, and one for the -docsite) merged and then wait for GitHub to release the version tags for each -project. Once this is done, we can now carry out the -last remaining tasks and announce the release. - -### Post release - -Update the links on the docsite to point to the new releases by updating the -version numbers in this -[file](https://github.com/seL4/docs/blob/master/_config.yml). - -Announce on the mailing list as well as the seL4 Discourse that the new release -is done. Update the line in this [file](_includes/custom-navbar.html) to point -to the seL4 Discourse announcement. - -Build a new version of the seL4 kernel manual and add it -[here](https://github.com/seL4/website/tree/master/content/Info/Docs) and -update the symlink to point to it. - -Finally, go to the release tool and run the following command while replacing -the fields: - -```shell -./releaseit postrelease --sel4-new-version= --camkes-new-version= --capdl-new-version= -``` - -This command will add version tags to each sub-project repository for each of -the repositories that are under those projects. Running it without the -`--release` flag will perform a dry-run. If there are issues during the dry-run, -fix them up and when everything is all good, run it with the `--release` flag. - -Now, the final task to do it to go to the GitHub pages for the seL4, CAmkES, -and capDL projects and draft new GitHub releases for each of the projects. - -Once you're here, hurray the release is done!