Bug #497
Updated by Felix Singer 10 months ago
# Overview schedule | | Time Date | Affects | Events | |---|-----------|----------------------------------------------|-----------------| |---|------------|-------------------------------|-----------------| | ✘ ✔ | T-6 weeks 1337-42-10 | `master` `main` | Sending announcement & starting with release preparations Announcement 1 | | ✘ ✔ | T-4 weeks 1337-42-11 | `master` `main` | Freezing of toolchain | | ✘ | T-2 weeks | `master` | Sending reminders & fix release date | | ✘ | T-1 week Announcement 2 | `master` | Finalize release preparations | | ✘ ✔ | T-1 day 1337-42-12 | `master` `main` | Double checking everything is fine ??? | | ✘ ✔ | T-0 1337-42-13 | `master`, `tag: 4.21`, `branch: 4.21_branch` `main`, `4.21`, `4.21_branch` | Working through the release process All bugs fixed! | | ✘ | T+1 week 1970-01-01 | `master`, `branch: 4.21_branch` UEFI | Announcing the release Getting rid of UEFI | # Tasks ### ~6 ## ~2 weeks prior to release * [_] `[x] Announce upcoming release to mailing list, ask people to test and to update release notes. notes.` @flx * [_] `[x] Start marking patches that should to go into the release with a tag "coreboot_release_X.yy" “coreboot_release_X.yy”` @flx ### ~4 weeks ## ~1 week 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. notes.` @flx * [_] `[ ] Update the topic in the IRC channel with the date of the upcoming release. ### ~1 week prior to release 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. notes.` * [_] `[ ] Finalize release notes as much as possible possible` * [_] `[ ] Prepare release notes template for following release release` * [_] `[ ] Update `Documentation/releases/index.md` 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. notes.` ### ## Day before release * [_] [X] Make sure patches with tags for the release are merged. @flx * [_] [X] Announce to IRC that the release will be tomorrow and ask for testing. @flx * [_] [X] Run `util/vboot_list/vboot_list.sh` util/vboot_list/vboot_list.sh script to update the list of boards supported by vboot. @flx ### ## Day of release * [_] Review the full documentation about doing the release below. @flx * [_] Select a commit ID to base the release upon. @flx * [_] 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 This is the actual release step.* 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" “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` 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.