Bug #497
Updated by Felix Singer over 1 year ago
# Overview schedule
| | Time | Affects | Events |
|---|-----------|------------------------------------------|-----------------|
| ✘ | T-6 weeks | `b: master` | Sending announcement & starting with release preparations |
| ✘ | T-4 weeks | `b: master` | Freezing of toolchain |
| ✘ | T-2 weeks | `b: master` | Fixing release date & sending reminders |
| ✘ | T-1 week | `b: master` | Finalizing release preparations |
| ✘ | T-1 day | `b: master` | Double checking everything is fine |
| ✘ | T-0 | `b: master`, `t: 4.21`, `b: 4.21_branch` | Release! |
| ✘ | T+1 day | `b: master`, `b: 4.21_branch` | Post-release steps & last minute fixes |
| ✘ | T+1 week | `b: master` | Announcement |
# Task list
### ~6 weeks prior to release
* [_] Announce upcoming release to mailing list, ask people to test and to update release notes.
* [_] Start marking patches that should to go into the release with a tag `coreboot_release_4.21`
### ~4 weeks prior to release
* [_] Freezing toolchain state. Only relevant and important fixes are allowed from this point on.
### ~2 weeks prior to release
* [_] Send reminder email to mailing list, ask for people to test, and to update the release notes.
* [_] Update the topic in the IRC channel with the date of the upcoming release.
### ~1 week prior to release
* [_] If there are any deprecations announced for the following release, make sure that a list of currently affected boards and chipsets is part of the release notes.
* [_] Finalize release notes as much as possible
* [_] Prepare release notes template for following release
* [_] Update `Documentation/releases/index.md`
* [_] Check which branches need to be released. Any branch with changes should get a new release. Announce these branch releases and prepare release notes.
### Day before release
* [_] Make sure patches with tags for the release are merged.
* [_] Announce to IRC that the release will be tomorrow and ask for testing.
* [_] Run `util/vboot_list/vboot_list.sh` script to update the list of boards supported by vboot.
### Day of release
* [_] Review the full documentation about doing the release below.
* [_] Select a commit ID to base the release upon.
* [_] Test the commit selected for release.
* [_] Submit last pre-release release notes.
* [_] Run the release script.
* [_] Test the release from the actual release tarballs.
* [_] Push signed Tag to repo. *This is the actual release step.* Once this patch is pushed, the release itself has been done. everything after this step is packaging and delivering the release.
* [_] Announce that the release tag is done on IRC.
* [_] Update the topic in the IRC channel that the release is done.
* [_] Do the final release notes - Fill in the release date, remove "Upcoming release" and other filler from the current release notes.
* [_] ADMIN: Upload release files to web server.
* [_] ADMIN: Upload the final release notes to the web server.
* [_] ADMIN: Upload crossgcc sources to web server.
* [_] Create coreboot-sdk and coreboot-jenkins-node docker images based on the release ID and push them to dockerhub. These can be used as release builders.
### Week following the release
* [_] Update download page to point to files, push to repo.
* [_] Write and publish blog post with release final notes. Branch releases notes should be included in the same post.
* [_] Remove code that was announced it was going to be removed.
* [_] Update `Documentation/releases/boards_supported_on_branches.md`