diff --git a/docs/develop/release/index.rst b/docs/develop/release/index.rst index 34c9435dad..64f707d731 100644 --- a/docs/develop/release/index.rst +++ b/docs/develop/release/index.rst @@ -51,48 +51,3 @@ to drive Haiku towards this release date. Release dates can slide, it's ok. We just try to slide pragmatically (+1 week because of X,Y,Z) - -Branch ------- - -Once a branch date is selected, branch haiku and buildtools into a "releasename" branch. (examples: r1beta3,r1beta4,r1.0,r1.1,etc) -Immeadiately after branching, do a ```pkgman full-sync``` of each haikuports builder to the latest nightly image. - -Before haiku branch: - -* B_HAIKU_VERSION changes to PRE_NEXTRELEASE via headers/os/BeBuild.h -* Stable version and pre-XXX version added to headers/os/BeBuild.h -* changes to next version via build/jam/BuildSetup - -see f56175 for an example - -*branch* - -After haiku branch: - -* Change B_HAIKU_VERSION to release name -* Update libbe_version from Walter to release name -* Set KDEBUG_LEVEL 1 in kernel_debug_config.h - -see 49073e , 5bf3dd for examples - - -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 releasename/toolchain-releasename to generate the intial toolchain containers -* Build each architecture first repo + image from the branch - - -Do Release Builds ---------- - -* Begin testing "Test Candidate" (TC0, TC1, TC2, etc) images -* Test like crazy, hand out test candidate images. -* Nominate a "Release Candidate" (RC0, RC1, etc) image -* Test like crazy, hand out release candidate images. -* Decide which Release Candidate will be the release. Rename it as the final release diff --git a/docs/develop/release/milestones.rst b/docs/develop/release/milestones.rst index a84d9d61d4..e3b39ad6d4 100644 --- a/docs/develop/release/milestones.rst +++ b/docs/develop/release/milestones.rst @@ -40,30 +40,33 @@ Branch * Branch haiku and buildtools (git push origin master:r1beta1) * Update the version constants in the branch (`example `_) * Update copyright years in the `bootloader menu `_ - * Tag the buildtools & point the branch to them (TODO) * Disable serial debug output in bootloader and kernel config file (`example `_) * Turn KDEBUG_LEVEL down to 1, for performance reasons (`example `_) * Update Haiku's main package repos to use the branch's repo (`example `_) -* Sysadmin tasks - * Symlink the release branch repository directory to master's (so that a hard branch can be done later) and update the package repos to point to it (`example `_) - * Synchronize userguide and locale catalogs in the branch during the release stabilization phase - * Add *(RELEASE)* to CI/CD (Concourse) - * generate toolchain container for *(RELEASE)* - * begin Test Candidate builds for target architectures (x86_gcc2h, x86_64) - * Test Candidate (TC) builds should be clearly labeled and made available -* Merge important bug fixes from master on a case-by-case basis. Ideally the release coordinator should review most of the changes and decide if they go in - * Use Gerrit "cherry-pick" function to propose a change for inclusion in the release branch - * Only merge bug fixes and build fixes, no new features at this point (they can stay in master) + * Update Haiku's haikuports repo to use the branch's repo (`example `_) + +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 ------------ @@ -71,7 +74,7 @@ Finalization **Time:** ~ 1 week * If everything is going well, produce Release Candidate images -* Make the branch officia (hrev36768) +* 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.