docs/release: Extend release engineering documentation

Change-Id: Iade40740e6dfbc7ea5f3f74f572d70443f94841a

docs/develop/release/index.rst

@@ -52,3 +52,47 @@ 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