Critical Milestones

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.

Scramle. 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 (part 1, part 2)

Configure CI/CD Pipelines

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

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 with drivers

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

Finalization

Time: ~ 1 week

  • If everything is going well, produce Release Candidate images

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

  • RC images all want to be (RELEASE)

  • Any RC image can be renamed (RELEASE)

  • Ensure release notes and press release are almost done.

  • MOAR 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 http://haiku-files.org/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)

  • Give mirrors time to… mirror via rsync

  • Tell Distrowatch: http://distrowatch.com/table.php?distribution=haiku (?)

  • Update the freshmeat/freecode page: http://freecode.com/projects/haiku (mmu_man)

  • Update website references.

    • Double check listed mirrors have release

    • Comment out any mirrors which don’t have it (a few missing is fine)

    • Put release notes on proper place on website

  • Release!

After the release

  • Close the current milestone on Trac, move tickets to the next milestone

  • Set a release date on the next milestone (a date long in the future, just to have it show first in the milestone list)

  • Make the new “version” in Trac be the default for newly creatred tickets

  • Update the Roadmap wiki page again with the final release date

  • Prepare graphics for the download page: stamp, ladybugs, cd/dvd graphics

Website Pages to update:

Updating download logo for website front page:

sudo bash
cd /srv/www/drupal/haiku-os.org/themes/shijin/haiku-images
mv bg-download-box.png GET-HAIKU-download-box-r1a1.png
cp GET-HAIKU-download-box-r1a2.png bg-download-box.png