💾 Archived View for lofi.haiku-os.org › docs › develop › release › milestones.gmi captured on 2023-12-28 at 15:16:21. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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

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 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:

Official Article

http://www.haiku-os.org/get-haiku

http://www.haiku-os.org/get-haiku/release-notes

http://www.haiku-os.org/get-haiku/installation-guide

http://www.haiku-os.org/get-haiku/burn-cd

http://www.haiku-os.org/guides/making_haiku_usb_stick

http://www.haiku-os.org/slideshows/haiku-tour

http://www.haiku-os.org/docs/userguide/en/contents.html

– sync with branch or tag.

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