Release Cookbook

This page documents the steps needed during a release.

Community Concensus

Determine a release is needed

Gain support in the community* Review the list of Trac tickets in the milestone. There should be no blockers and ideally no critical tickets

Decide if some of the tickets can be lowered in priority or moved to the next release

Raise release proposal on mailing list (haiku-development)* Select Release Coordinator

Plan timeline (which should be made up of milestones below)

Allow one week RFC time for comments

Each of the steps below should be announced on the mailing list to remind everyone where we’re at.

Scramble. Enhancement Deadline

**Time:** ~ 1 week

Roughly one week for people to finish up their enhancements for *(RELEASE)*

Avoid merging changes that break the API, so 3rd-party applications are ready to build with the API matching the release

Decide if any haikuports packages should be added or removed from the release image

Final ICU upgrades, webkit upgrades, etc.

Plan for release logo used in installer (always fun, lots of bikeshed)* Prepare this in advance if possible, if you want to change the logo, this is the worst time to do it.

Set up the

Trac wiki pages

for the release* Start writing or updating the release notes and press release

Branch

**Time:** ~ 1 week

Update the version constants in master (

example: hrev52295

)

Branch haiku and buildtools (git push origin master:r1beta1)* Update the version constants in the branch (

example

)

Update copyright years in the

bootloader menu

Disable serial debug output in bootloader and kernel config file (

example

)

Turn KDEBUG_LEVEL down to 1, for performance reasons (

example

)

Enable "HAIKU_OFFICIAL_RELEASE" (

example

), and update logos

Update both package repos to use the branch’s repos (

example

)

Configure CI/CD Pipelines

Once your code is branched, you can begin setting up CI/CD pipelines in concourse

Bump the “last vs current” releases in CI/CD and deploy:

https://github.com/haiku/infrastructure/blob/master/concourse/deploy.sh#L29

Run a build of *(RELEASE)*/toolchain-*(RELEASE)* to generate the intial toolchain containers

Build each architecture first repo + image from the branch

Testing

**Time:** ~ 2 weekes

Begin building “Test Candidate” (TC0, TC1, TC2, etc) images for target architectures (x86_gcc2h, x86_64) * Test Candidate (TC) builds should be clearly labeled and made available

Agressively market Test Candidate builds for *(RELEASE)*

Bugs should be opened on Trac under the *new* version (make sure it is available in Trac admin pages).

**Release Coordinator** should be downright obnoxious about people testing TC images!

Have people test on as much hardware as possible to find issues

Use Gerrit “cherry-pick” function to propose a change for inclusion in the release branch

Finalization

**Time:** ~ 1 week

Synchronize **i18n** strings and userguide

Produce **Release Candidate** images

**Tag** the release candidate builds on the brach (rc0)

Ensure release notes and press release are almost done.

More testing!

When you have decided that an RC is actually the release, tag it in git

Distribution

**Time:** ~ 1 week

You now have the release images in hand! (RCX is secretly the release)* Keep it to yourself and don’t tell people

Generate Torrents, seed. Get a few other people to seed.

Place onto wasabi s3 under releases in final layout (be consistent!)

Move to releases onto IPFS, pin and use pinning services

Prepare release-files-directory:

[release-name]
 |--md5sums.txt (of compressed and uncompressed release-image-files)
 |--release_notes_[release-name].txt
 |--[release-image-files]  (both as .zip and .tar.xz)
 |--[release-image-files].torrent (of just the .zip's)
 |--[release-name]/sources/   (all source archives should be .tar.xz)
      |--haiku-[release-name]-src-[YYYY-MM-DD]
      |--haiku-[release-name]-buildtools-src-[YYYY-MM-DD]
      |--[all optional packages]

rsync release-files-directory to /files/releases/[release-name]

rsync release-files-directory to baron:/srv/rsync/haiku-mirror-seed/releases/[release-name]/ (the 3rd-party rsync mirrors will automatically mirror the files)