1Release Cookbook 2=================== 3 4This page documents the steps needed during a release. 5 6Community Concensus 7------------------- 8 9* Determine a release is needed 10* Gain support in the community 11 * Review the list of Trac tickets in the milestone. There should be no blockers and ideally no critical tickets 12 * Decide if some of the tickets can be lowered in priority or moved to the next release 13* Raise release proposal on mailing list (haiku-development) 14 * Select Release Coordinator 15 * Plan timeline (which should be made up of milestones below) 16 * Allow one week RFC time for comments 17 18Each of the steps below should be announced on the mailing list to remind everyone where we're at. 19 20Scramble. Enhancement Deadline 21------------------------------ 22 23**Time:** ~ 1 week 24 25* Roughly one week for people to finish up their enhancements for *(RELEASE)* 26* Avoid merging changes that break the API, so 3rd-party applications are ready to build with the API matching the release 27* Decide if any haikuports packages should be added or removed from the release image 28* Final ICU upgrades, webkit upgrades, etc. 29* Plan for release logo used in installer (always fun, lots of bikeshed) 30 * Prepare this in advance if possible, if you want to change the logo, this is the worst time to do it. 31* Set up the `Trac wiki pages <https://dev.haiku-os.org/wiki/R1/ReleaseRoadMap>`_ for the release 32 * Start writing or updating the release notes and press release 33 34Branch 35------ 36 37**Time:** ~ 1 week 38 39* Update the version constants in master (`example: hrev52295 <https://git.haiku-os.org/haiku/commit/?h=hrev52295>`_) 40* Branch haiku and buildtools (git push origin master:r1beta1) 41 * Update the version constants in the branch (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=b5c9e6620ee731bd33d8cb3ef6ac01749122b6b3>`_) 42 * Update copyright years in the `bootloader menu <https://git.haiku-os.org/haiku/tree/src/system/boot/platform/generic/text_menu.cpp#n212>`_ 43 * Disable serial debug output in bootloader and kernel config file (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta5&id=9d0312eb00a75051275accf9967ddc1c64154334>`_) 44 * Turn KDEBUG_LEVEL down to 1, for performance reasons (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=6db6c0b275f684d0b25d49e87d5183e40c7cd4ec>`_) 45 * Enable ``HAIKU_OFFICIAL_RELEASE`` (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=ff2059f2bd001bba84b980617e9bdf4dc6a46799>`_), and update logos 46 * Update both package repos to use the branch's repos (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta4&id=b9c0fea70a1fd7edc396e0e6992b77a7c5a3b4f8>`_) 47 48Configure CI/CD Pipelines 49------------------------- 50 51Once your code is branched, you can begin setting up CI/CD pipelines in concourse 52 53* Bump the "last vs current" releases in CI/CD and deploy: 54 https://github.com/haiku/infrastructure/blob/master/concourse/deploy.sh#L29 55* Run a build of *(RELEASE)*/toolchain-*(RELEASE)* to generate the intial toolchain containers 56* Build each architecture first repo + image from the branch 57 58Testing 59------- 60 61**Time:** ~ 2 weekes 62 63* Begin building "Test Candidate" (TC0, TC1, TC2, etc) images for target architectures (x86_gcc2h, x86_64) 64 * Test Candidate (TC) builds should be clearly labeled and made available 65* Agressively market Test Candidate builds for *(RELEASE)* 66* Bugs should be opened on Trac under the *new* version (make sure it is available in Trac admin pages). 67* **Release Coordinator** should be downright obnoxious about people testing TC images! 68* Have people test on as much hardware as possible to find issues 69* Use Gerrit "cherry-pick" function to propose a change for inclusion in the release branch 70 71Finalization 72------------ 73 74**Time:** ~ 1 week 75 76* Synchronize **i18n** strings and userguide 77* Produce **Release Candidate** images 78* **Tag** the release candidate builds on the brach (rc0) 79* Ensure release notes and press release are almost done. 80* More testing! 81* When you have decided that an RC is actually the release, tag it in git 82 83Distribution 84------------ 85 86**Time:** ~ 1 week 87 88* You now have the release images in hand! (RCX is secretly the release) 89 * Keep it to yourself and don't tell people 90* Generate Torrents, seed. Get a few other people to seed. 91* Place onto wasabi s3 under releases in final layout (be consistent!) 92* Move to releases onto IPFS, pin and use pinning services 93* Prepare release-files-directory:: 94 95 [release-name] 96 |--md5sums.txt (of compressed and uncompressed release-image-files) 97 |--release_notes_[release-name].txt 98 |--[release-image-files] (both as .zip and .tar.xz) 99 |--[release-image-files].torrent (of just the .zip's) 100 |--[release-name]/sources/ (all source archives should be .tar.xz) 101 |--haiku-[release-name]-src-[YYYY-MM-DD] 102 |--haiku-[release-name]-buildtools-src-[YYYY-MM-DD] 103 |--[all optional packages] 104 105* rsync release-files-directory to /files/releases/[release-name] 106* rsync release-files-directory to baron:/srv/rsync/haiku-mirror-seed/releases/[release-name]/ (the 3rd-party rsync mirrors will automatically mirror the files) 107* Give mirrors time to... mirror via rsync 108* Tell Distrowatch: http://distrowatch.com/table.php?distribution=haiku (?) 109* Update website references. 110 * Double check listed mirrors have release 111 * Comment out any mirrors which don't have it (a few missing is fine) 112 * Put release notes on proper place on website 113* Release! 114 115Website Pages to update: 116 117* https://www.haiku-os.org/ "Download" button 118* https://www.haiku-os.org/get-haiku 119* https://www.haiku-os.org/get-haiku/release-notes 120* https://www.haiku-os.org/get-haiku/installation-guide 121* https://www.haiku-os.org/get-haiku/burn-cd 122* https://www.haiku-os.org/guides/making_haiku_usb_stick 123* https://www.haiku-os.org/slideshows/haiku-tour 124* https://www.haiku-os.org/docs/userguide/en/contents.html -- sync with branch or tag. 125 126 127After the release 128----------------- 129 130* Close the current milestone on Trac, move tickets to the next milestone 131* Set a release date on the next milestone (a date long in the future, just to have it show first in the milestone list) 132* Make the new "version" in Trac be the default for newly creatred tickets 133* Update the Roadmap wiki page again with the final release date 134* Prepare graphics for the download page: stamp, ladybugs, cd/dvd graphics 135