Bug #497
Updated by Felix Singer 11 months ago
# ~2 weeks prior to release
[x] [ ] Announce upcoming release to mailing list, ask people to test and to update release notes.
[x] [ ] Start marking patches that should to go into the release with a tag “coreboot_release_X.yy”
# ~1 week 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.
[ ] 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.