1Release engineering 2=================== 3 4To forge a successful stable release of the Haiku operating system, several important tasks must be 5accomplished. These steps are time tested as a best roadmap to draft a successful release of Haiku. 6 7.. toctree:: 8 9 milestones 10 11Important first steps 12--------------------- 13 14* Review blockers for the next release in `Trac <https://dev.haiku-os.org>`_ 15* Active members of the `contributors group <https://review.haiku-os.org/admin/groups/23fa29f291e2dd5d41452202147d038f020fc8db,members>`_ should reach concensus on the need for a stable release 16 * We try to have a release every year, but blocker tickets can prevent this from happening 17 * It's difficult to commit to strictly time-based releases because the available time of unpaid developers is unpredictable 18* Community nomination of a Release Coordinator 19 * Should be someone from the contributors group 20 * Should have visibility of most aspects of Haiku 21 * Should have good coordination and communication skills 22 * Generally occurs via the haiku-development mailing list 23 * Timeline proposals are proposed via the haiku-development mailing list 24 25General Rules 26------------- 27 28* Don't rush the release. Better delay it a bit and take the time to make sure everything is ok. 29* Make sure the final image is really well tested. 30* Start planning early. Getting the release ready takes time. Waiting until a new release is urgent is a bad idea. 31* There will be another release. Maybe some big changes are too risky to integrate now, and should wait until the next release. 32 33Forming a timeline 34------------------ 35 36An important aspect of drafting a release is forming a timeline. The Release Coordinator's role is 37to drive Haiku towards this release date. 38 39* Final date for enhancements in (RELEASE) 40* Branch buildtools for (RELEASE) 41* Branch haiku for (RELEASE) 42* Setup CI/CD pipelines for (RELEASE) 43* Generate first test candidates (TC0, TC1, etc), encourage extreme testing. 44* Begin accepting bugfixes in branches via code review 45* Final translations synchronization 46* Generate first release candidates (RC0, RC1, etc), encourage testing. 47* Profit 48 49* R1/Beta 2's timeline from branch to release was roughly 35 days 50* R1/Beta 3's timeline from branch to release was roughly 50 days. 51 52Release dates can slide, it's ok. 53We just try to slide pragmatically (+1 week because of X,Y,Z) 54