Version 17 (modified by waddlesplash, 2 years ago) ( diff )


This page gathers random notes about doing Haiku releases.

General rules

Take care of this:

  • Don't rush the release. Better delay it a bit and take the time to make sure everything is ok.
  • Make sure the final image is really well tested.
  • Start planning early. Getting the release ready takes time. Waiting until a new release is urgent is a bad idea.


This is an actual phase of the release schedule. It's purpose is to grab the attention of all contributors -- committers, bug reporters, translators, everyone.

Getting the development team in "release mode" is not easy. The Trac roadmap is a good indicator of how close we are, but there is some "under the hood" stuff that's hard to predict, like important work happening in a branch we'd really want to merge.

  • Announce the intent to enter release mode: ML, Website. At this point, we should already have a release coordinator.
  • Define the schedule and target date.
  • Cleanup the Trac roadmap of mistargeted tickets: most stuff can be postponed.
  • Allow developers to push any remaining drastic changesets
  • Selection of haikuports packages that should be in the package repo, and first run of build and testing for these.
  • Make sure the API stays stable (Services Kit, Layout Kit, Locale Kit) for some time before the release so 3rd-party app can be up to date on it.
  • Complete the release roadmap and set the purpose for the release: R1/ReleaseRoadMap
  • Setup the wiki pages for the release (R1/Beta1)
  • Fix all the blocking bugs


  • Update the version constants in master (hrev52295)
  • Create the branch (git push origin master:r1beta1)
  • Update the version constants in the branch (b5c9e6620)
  • Tag the buildtools & point the branch to them (TODO)
  • Disable serial debug output in bootloader and kernel config file (81fb2084b)
  • Turn KDEBUG_LEVEL down to 1, for performance reasons (6db6c0b275)
  • Update Haiku's main package repos to use the branch's repo (ebd3fb55d95)
  • Branch the HaikuPorts Buildmaster and update the package repos to point to it (TODO)
  • Fix any remaining bugs [merge stuff from master on an exceptional basis] and do general polishing. Give some preview to people so they can test it.
  • Import user guide (hrev36743, hrev36744) and synchronize locale catalogs
  • Freeze the branch
  • Make the branch official (hrev36768)
  • Add the ladybugs, stamp in installer logo, etc.
  • Make sure the anyboot image size does not exceed 694 MB
  • Have a test run of the golden master image to spot last remaining critical bugs
  • Cooldown phase: testing of the golden master image on as much hardware as possible: booting, installing, using, for all image types (anyboot, iso, vmware).
  • Tag the branch
  • Write the release notes and press releases
  • Prepare release-files-directory:
      |--md5sums.txt (of compressed and uncompressed release-image-files)
      |--[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)
           |--[all optional packages]
  • rsync release-files-directory to[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)
  • Tell Distrowatch: (?)
  • Update the freshmeat/freecode page: (mmu_man)

After the release

  • Create new Trac "version" and close current milestone
  • Create source archives for legal purposes (GPL compliance)
  • 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/
mv bg-download-box.png GET-HAIKU-download-box-r1a1.png
cp GET-HAIKU-download-box-r1a2.png bg-download-box.png
Note: See TracWiki for help on using the wiki.