Improve Apertis Release Process

Rework the Apertis Release Process guide to:
- Make clear what are the differences between developement/preview
  releases and stable ones
- Have a clear high level view of the release process

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

content/guides/apertis_release_process.md

@@ -28,20 +28,28 @@ At a higher level, Apertis infrastructure includes:
 * images.apertis.org for Apertis image hosting
 * LAVA for Quality Assurance Testing
 
-# Release Preparation
+# Development/Preview Releases
 
-Below are a list of tasks that are usually required to be run before planning the execution of a release.
+As described in [Release flow and product lines]({{< ref release-flow.md >}}) Apertis ships three types of releases: development, preview and stable. This section describes the release process for development and preview releases.
+
+## Development/Preview Release Steps
+
+As a high level overview, these are the steps to be executed during the release cycle, to perform a release:
 
-* Check available disk space on OBS Server
-  * *Release Branching* is a task that will consume a significant amount of disk space. Thus, it is very important to ensure that enough free space is available before commencing a release branching. Depending upon the size of a project, the amount of disk space required can vary.
-  * Running out of disk space, halfway during the *release branching* process, may have severe side-effects. Hence, it is advised to consider over provision of free disk space before initiating a *release branching*.
 * Keep release schedule wiki page updated
 * Announce soft feature freeze
 * Full archive rebuild (in the rebuild repository, not on the main one) to ensure all the packages are buildable from sources. See the the [Archive Rebuilds](#archive-rebuilds) section below
 * Announce hard feature freeze
 * Update the freshness status of all the design documents
-* Draft the release notes
-* Draft the internal release notes
+* Write the release notes
+* Confirm that no release blocker issue is present
+* Publish Release Candidate (RC1) images and announce hard code freeze
+* RC images validation (QA)
+* Check available disk space on OBS Server
+  * *Release Branching* is a task that will consume a significant amount of disk space. Thus, it is very important to ensure that enough free space is available before commencing a release branching. Depending upon the size of a project, the amount of disk space required can vary.
+  * Running out of disk space, halfway during the *release branching* process, may have severe side-effects. Hence, it is advised to consider over provision of free disk space before initiating a *release branching*.
+* Perform Release branching
+* Publish Release images
 
 ## Archive Rebuilds
 
@@ -68,7 +76,7 @@ Some notes about the `Archive Rebuild` task
 * Never trigger an archive wide rebuild on the primary repositories like target, sdk, development, hmi, helper-libs etc.
 
 
-# Release Branching
+## Release Branching
 
 Once the **Release Preparation** is complete, the next step in the **Release Process** is to run the **Release Branching** steps.
 
@@ -80,7 +88,7 @@ At a higher level, **Release Branching** includes the following steps which need
 * Branching docker image recipes
 * Branching all OBS repositories
 
-## Release Branching through Gitlab CI
+### Release Branching through Gitlab CI
 
 The release process has been semi-automated with the [Gitlab CI framework](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/pipelines). The following screenshots/notes will give a run through of the steps, to make a release.
 
@@ -131,7 +139,7 @@ Most manual jobs are made dependent on other job. This is to ensure that steps a
 The above example complete the *semi-automated* aspect of the **Release Branching** steps.
 
 
-### Skipping jobs
+#### Skipping jobs
 
 There can be scenarios during the *Release Branching* wherein the user would be required to re-run the entire pipeline. Under such situation, it can be desired to have certain specific jobs to be skipped from the consecutive pipeline run. For example, in first run, `branch-create-mass-branches` was run and it created all the branches in respect to the `NEXT_RELEASE`. For such cases, on consecutive run, it is desired to skip the `branch-create-mass-branches` job. Below is an example on how to invoke the pipeline while defining a set of jobs to be skipped.
 
@@ -143,7 +151,7 @@ In the above example screenshot, we specify that the `branch-create-mass-branche
 
 As was specified in the previous job invocaton, this example pipeline job run has the `branch-create-mass-branches` and `branch-update-tests-projects` skipped.
 
-## Post CI Manual Steps
+### Post CI Manual Steps
 
 After the completion of the **Release Branching** CI Jobs, a certain set of manual steps need to be performed, which are outlined below.
 
@@ -158,7 +166,7 @@ After the completion of the **Release Branching** CI Jobs, a certain set of manu
   * Validate the newly created pipeline ensuring that it generates the right set of changes with respect to the new release.
   * Validate the new package is built proper and pushed to OBS and the APT repositories
 
-## Build Suffix
+### Build Suffix
 
 For every release (Developer, Preview, Product), we add a build suffix string to the packages, which relates to the release name of Apertis. The build suffix gets added to every built .deb package. Having a build suffix helps determine which Apertis release the .deb package was built for.
 
@@ -170,16 +178,22 @@ The suffix string is constructed of: `b + Release Name + b<B_CNT>`
 For example, for an Apertis Developer Release of `v2020dev0`, we add string `bv2020dev0b<B_CNT>` to the project configuration on OBS.
 Similarly, for an Apertis Product Release of `v2019.0`, we add string `bv2019.0b<B_CNT>` to the project configuration on OBS
 
-## Stable Build Suffix
-
-Ensure to update the build suffix on the project configs when doing a Stable Point Release
+## Publish Release Candidate
 
-For Point Releases (Eg. v2019.1, v2019.2), we need to update the build suffix to ensure that the packages in the new point release have a higher version than the one in the updates or security repository.
-
-For example, during a release, the build suffix for a `v2019` release is: `bv2019.0b<B_CNT>`. The same build suffix is inherited by the *:updates* and *:security* sub-repository. Before doing a new point release `v2019.1`, we need to set the build suffix of the main repositories (*apertis:v2019:target*, *apertis:v2019:development*, *apertis:v2019:sdk*, *apertis:v2019:hmi* etc) to `vb2019.1b<B_CNT>`.
+* Run the `copy-release` script on the images server (aura) to prepare the RC.
+ * `copy-release -v 20201203.0116 v2021pre.0rc1`
+ * `copy-release -v -i 20201203.0116 v221pre.0rc1`
+ * First for the public images and then second for Internal images (-i option).
+ * The source folder is picked from the daily image builds.
+* Send release announcement for the release.
 
-This will ensure that the packages synced from the *:updates* and *:security* sub-repository will have a higher version, when they are synced to the main repository
+## Publish Release
 
+* Run the `copy-release` script on the images server (aura) to prepare the RC.
+ * `copy-release -v -r v2021pre.0rc1 v2021pre.0`
+ * `copy-release -v -i -r v2021pre.0rc1 v2021pre.0`
+ * First for the public images and then second for Internal images (-i option).
+ * Send release announcement for the release.
 
 # Stable Point Release
 
@@ -190,36 +204,36 @@ A Stable Point Release includes:
 * Normal updates to software packages (funneled through $RELEASE-updates). These include bug fixes to existing version of software packages.
 * Backport of software packages (funneled through $RELEASE-backports). These include newer version of software packages backported to older OS releases
 
-## Stable Point Release Preparation
+## Stable Point Release Steps
 
-* Increment the *Build Suffix* in the Project configuration for each repository relevant to the release. See section **Build Suffix** for more details
-* Run the [`fold-security-update-branches`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/gitlab/fold-security-update-branches) script to:
-  * List the packages in the `:security`, `:updates` and other similar repositories
-  * Fast Forward Merge `--ff-only` the respective security and updates branches on Git. For example, `apertis/v2019-security` and `apertis/v2019-updates` should be merged back to `apertis/v2019`. Note: Not able to perform a fast forward merge means something got broken and needs to be investigated and fixed.
-  * Poke the pipeline and ensure that all the new packages (from the merged back changes to `apertis/v2019`) get built on OBS and land into the main repository.
-  * Drop the *updates*, *security* branches (Eg. `apertis/v2019-updates`, `apertis/v2019-security`)
-  * Delete the packages from the *updates*, *security* etc repositories on OBS (Eg. `apertis:v2019:updates:target`, `apertis:v2019:security:development`)
-* Manually validate that the `fold-security-update-branches` script has merged all the updates into main repository
-* Rebuild the image to pick up the updated packages in the main repository.
-* Run the `copy-release` script on the images server (aura) to prepare the release.
- * `copy-release -v 20191120.0 v2019.1rc2`
- * `copy-release -v -i 20191120.0 v2019.1rc2`
- * First for the public images and then second for Internal images (-i option).
- * The source folder is picked from the daily image builds.
-* Send release announcement for the release.
+* Keep release schedule wiki page updated
+* Announce soft feature freeze
+* Full archive rebuild (in the rebuild repository, not on the main one) to ensure all the packages are buildable from sources. See the the [Archive Rebuilds](#archive-rebuilds) section below
+* Announce hard feature freeze
+* Check available disk space on OBS Server
+  * *Release folding* is a task that will consume a significant amount of disk space. Thus, it is very important to ensure that enough free space is available before commencing a release branching. Depending upon the size of a project, the amount of disk space required can vary.
+  * Running out of disk space, halfway during the *release folding* process, may have severe side-effects. Hence, it is advised to consider over provision of free disk space before initiating a *release branching*.
+* Perform release folding
+* Write the release notes
+* Confirm that no release blocker issue is present
+* Publish Release Candidate (RC1) images and announce hard code freeze
+* RC images validation (QA)
+* Publish Release images
+
+Several of the steps above were already described in the previous section, the following section will describe
+those steps specific for stable point releases.
 
-## Stable Point Release  - Automated Steps
+## Folding Stable Point Release
 
 Launch `fold-security-update-branches` script from the *apertis-infrastructure/release-scripts/gitlab/*, which automates many of the steps in a *Stable Point Release Preparation*
 
+* Increment the *Build Suffix* in the Project configuration for each repository relevant to the release. See section **Build Suffix** for more details
 * List the packages in the `:security`, `:updates` and other similar repositories
 * Fast Forward Merge `--ff-only` the respective security and updates branches on Git. For example, `apertis/v2020-security` and `apertis/v2020-updates` should be merged back to `apertis/v2020`. Note: Not able to perform a fast forward merge means something got broken and needs to be investigated and fixed.
 * Poke the pipeline and ensure that all the new packages (from the merged back changes to `apertis/v2020`) get built on OBS and land into the main repository.
 * Drop the *updates*, *security* branches (Eg. `apertis/v2020-updates`, `apertis/v2020-security`)
 * Delete the packages from the *updates*, *security* etc repositories on OBS (Eg. `apertis:v2020:updates:target`, `apertis:v2020:security:development`)
 
-Following are the example runs for the automation script.
-
 ### Example Run with help sub-command
     rrs@priyasi:~/$ ./fold-security-update-branches  help
     Usage: ./fold-security-update-branches [apply] [gen-pkg-list] [dry-run] [help]
@@ -298,6 +312,16 @@ obsolete *Beta* and *Preview* distribution releases, like: `v2019dev0`, `v2019pr
   Deleting vanished identifier 'u|v2019pre|proprietary|armhf'.
   ```
 
+## Stable Build Suffix
+
+Ensure to update the build suffix on the project configs when doing a Stable Point Release
+
+For Point Releases (Eg. v2019.1, v2019.2), we need to update the build suffix to ensure that the packages in the new point release have a higher version than the one in the updates or security repository.
+
+For example, during a release, the build suffix for a `v2019` release is: `bv2019.0b<B_CNT>`. The same build suffix is inherited by the *:updates* and *:security* sub-repository. Before doing a new point release `v2019.1`, we need to set the build suffix of the main repositories (*apertis:v2019:target*, *apertis:v2019:development*, *apertis:v2019:sdk*, *apertis:v2019:hmi* etc) to `vb2019.1b<B_CNT>`.
+
+This will ensure that the packages synced from the *:updates* and *:security* sub-repository will have a higher version, when they are synced to the main repository
+
 # Appendix
 
 ## Helper scripts to ease Apertis development