Project

General

Profile

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`, `t: 4.21` 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 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`

Back