Bug #497
Updated by Felix Singer 10 months ago
# Overview schedule | | Time | Affects | Events | |---|-----------|----------------------------------------------|-----------------| | ✘ | T-6 weeks | `master` | Sending announcement & starting with release preparations | | ✘ | T-4 weeks | `master` | Freezing of toolchain | | ✘ | T-2 weeks | `master` | Sending reminders & fix release date | | ✘ | T-1 week | `master` | Finalize release preparations | | ✘ | T-1 day | `master` | Double checking everything is fine | | ✘ | T-0 | `master`, `tag: 4.21`, `branch: 4.21_branch` | Release! Release | | ✘ | T+1 week | `master`, `branch: 4.21_branch` | Announcement & post-release steps | # Task list Tasks ### ~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_X.yy" ### ~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` ### Creating a branch * [_] Branches are named 4.xx_branch to differentiate from the tags. Instructions on creating branches are listed below.