github.com/openebs/node-disk-manager@v1.9.1-0.20230225014141-4531f06ffa1e/RELEASE.md (about)

     1  # Release Process
     2  node-disk-manager follows a monthly release cadence. The scope of the release is determined by contributor availability. The scope is published in the [Release Tracker Projects](https://github.com/orgs/openebs/projects).
     3  
     4  ## Release Candidate Verification Checklist
     5  
     6  Every release has release candidate builds that are created starting from the third week into the release. These release candidate builds help to freeze the scope and maintain the quality of the release. The release candidate builds will go through:
     7  - Platform Verification
     8  - Regression and Feature Verification Automated tests.
     9  - Exploratory testing by QA engineers
    10  - Strict security scanners on the container images
    11  - Upgrade from previous releases
    12  - Beta testing by users on issues that they are interested in.
    13  - Dogfooding on OpenEBS workload and e2e infrastructure clusters
    14  
    15  If any issues are found during the above stages, they are fixed and new release candidate builds are generated.
    16  
    17  Once all the above tests are completed, a main release tagged image is published.
    18  
    19  ## Release Tagging
    20  
    21  node-disk-manager is released as container image with versioned tag.
    22  
    23  Before creating a release, repo owner needs to create a separate branch from the active branch, which is `develop`. Name of the branch should follow the naming convention of `v0.5.x`, if release is for v0.5.0.
    24  
    25  Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder `changelogs/v0.5.x`, if release branch is `v0.5.x`.
    26  
    27  The format of the release tag is either "Release-Name-RC1" or "Release-Name" depending on whether the tag is a release candidate or a release. (Example: v0.5.0-RC1 is a GitHub release tag for node-disk-manager release candidate build. v0.5.0 is the release tag that is created after the release criteria are satisfied by the node-disk-manager RC builds.)
    28  
    29  Once the release is triggered, Github Action release workflow has to be monitored. Once the workflow passes, images are pushed to docker hub and quay.io. Images can be verified by going through docker hub and quay.io. Also, the images shouldn't have any high level vulnerabilities.
    30  
    31  Images for the different components are published at the following location:
    32  
    33  - Node Disk Manager Daemon
    34      https://quay.io/repository/openebs/node-disk-manager?tab=tags
    35      https://hub.docker.com/r/openebs/node-disk-manager/tags
    36  
    37  - Node Disk Operator
    38      https://quay.io/repository/openebs/node-disk-operator?tab=tags
    39      https://hub.docker.com/r/openebs/node-disk-operator/tags
    40  
    41  - Node Disk Exporter
    42      https://quay.io/repository/openebs/node-disk-exporter?tab=tags
    43      https://hub.docker.com/r/openebs/node-disk-exporter/tags
    44  
    45  
    46  Once a release is created, update the release description with the change log mentioned in `changelog/v0.5.x`. Once the change logs are updated in release, repo owner needs to create a PR to `develop` with the following details:
    47  1. update the changelog from `changelog/v0.5.x` to `node-disk-manager/CHANGELOG.md`
    48  2. If release is not a RC tag then PR should include the changes to remove `changelog/v0.5.x` folder.
    49  3. If release is a RC tag then PR should include the changes to remove the changelog from `changelog/v0.5.x` which are already mentioned in `node-disk-manager/CHANGELOG.md` as part of step number 1.