Our releases aren’t primarily a vehicle for code that is stable across all
boards: The logistics of testing the more than 100 boards that are spread out
all continents (except Antarctica, probably) on a given tree state are
prohibitive for project of our size.

Instead, the releases are regular breakpoints that serve multiple purposes:
They support cooperation between multiple groups (corporations or otherwise)
in that it’s easier to keep source trees synchronized based on a limited set
of commits. They allow a quick assessment of the age of any given build or
source tree based on its git version (4.8-1234 was merged into master a few
months after 4.8, which came out in April 2018. 4.0-21718’s age is harder to
guess).

And finally we use releases to as points in time where we remove old code:
Once we decide that a certain part of coreboot gets in the way of future
development, we announce on the next release that we intend to remove that
part - and everything that depends on it - after the following release.
So removing feature FOO will be announced in release X for release
X+1. The first commit after X+1 is fair game for such removal.

Together with our 6 months release horizon, this provides time to plan
any migrations necessary to keep older boards in the tree by bringing
them up to current standards.

The announcement should state the planned release date, point to the
release notes that are in the making and ask people to test the hardware
they have to make sure it’s working with the current master branch,
from which the release will ultimately be derived from.

People should also be encouraged to provide additions to the
release notes, for example by putting them on some collaborative
editor.

The final release notes will reside in coreboot’s Documentation/releases
directory, so asking for additions to that through the regular Gerrit
process works as well. Note that git requires lots of conflict resolution
on heavily edited text files though.

Frequently, we will want to wait until particular things are in the
release. Once those are in, you can select the commit ID that you want
to use for your release. For the 4.6 release, we waited until we had
time to do the release, then pulled in a few patches that we wanted
to have in the release. The release was based on the final of those
patches to be pulled in.

When a release candidate has been selected, announce the commit ID to
the #coreboot irc channel, and request that it get some testing, just
to make sure that everything is sane.

After the commit for the release has been selected and verified, run the
release script - util/release/build-release. This will download a new
tree, checkout the commit that you specified, download the submodules,
create a tag, then generate and sign the tarballs.

Announce that the release has been tagged - this lets people know that
they should update their trees to grab the new tag. Until they do this,
the version number in build.h will still be based on the previous tag.

Copy the tarballs and .sig files generated by the script to
the coreboot server, and put them in the release directory at
/srv/docker/www.coreboot.org-staticfiles/releases/

%sha256sum-bcoreboot-*.tar.xz>sha256suma.txt# Update the sha256sum file%diffsha256sum.txtsha256suma.txt# make sure that the two new files are present (and that nothing else has changed)%mvsha256suma.txtsha256sum.txt

People can now see the release tarballs on the website at
https://www.coreboot.org/releases/

The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at https://review.coreboot.org/cgit/homepage.git/tree/downloads.html

Here is an example commit to change it: https://review.coreboot.org/#/c/19515/

At times we will need to create a branch, generally for patch fixes.
When making a branch, do NOT name it the same as the release tag: X.Y - this creates trouble when trying to check it out, as git can’t tell whether you want the tag or the branch.
Instead, name it X.Y_branch: gitcheckout4.8;gitcheckout-b4.8_branch;gitpushorigin4.8_branch