Skip to content

Latest commit

 

History

History
81 lines (56 loc) · 4.89 KB

RELEASE.md

File metadata and controls

81 lines (56 loc) · 4.89 KB

Release Process

Local PV LVM tries to follow semantic versioning principles as specified here https://semver.org. It follows a on quarterly release cadence for minor version releases. The scope of the release is determined by contributor availability. The scope is published in the Release Tracker Projects.

Pre-release Candidate Verification Checklist

Every release has a pre-release version that gets created on branch creation, explained further below. This pre-release version is meant for all the below action items throughout the release process:

  • Platform Verification
  • Automated Regression & Feature Testing
  • Exploratory Testing by QA engineers
  • Strict Security Scanning on container images
  • Upgrade Testing from previous releases
  • Beta Testing by users on relevant issues

If any issues are found during the above stages, they are fixed and the prerelease version is overridden by the newer changes and are up for above action items again.

Once all the above tests are completed, a main release is created.

Release Tagging

Local PV LVM is released with container images and a respective helm chart as the only recommended way of installation. Even though the lvm-operator is also published, it is generated by templating the helm chart itself.

Before creating a release, the 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 release/2.7 if release is for 2.7.x.

Upon creation of a release branch ex. release/2.7, two automated PRs open up to change the chart versions of the charts in release/2.7 branch to 2.7.0-prerelease and develop to 2.8.0-develop. Post merge of these two PRs, the 2.7.0-prerelease and 2.8.0-develop versions are pushed to respective docker registries and also the respective helm charts against these versions are published. The prerelease versions increment via automated PRs on every release creation. For example once 2.7.0 is published a 2.7.1-prerelease image and chart would be published to allow testing of further patch releases and so on.

The format of the release tag follows semver versioning. The final release tag is of format X.Y.Z and the respective prerelease and develop versions are X.Y.Z-prerelease and X.Y+1.0-develop.

Once the release is triggered, the unchanged code undergoes stages as such linting, unit-tests and bdd-tests and the code coverage is updated accordingly. Post the former jobs, the image build is triggered with the specified tag, the images are published and the chart is run though scripts that update the image tags at the relevant places and eventually helm charts are published.

The helm charts are hosted on github deployments for the corresponding releases.

  1. Automated Version Updates:

    • Two automated PRs update chart versions:
      • release/2.7 branch → 2.7.0-prerelease
      • develop branch → 2.8.0-develop
    • Once merged, the updated images and Helm charts are published for testing.

  2. Final Release Creation:

    • When the release branch is ready, the repo owner creates a release with tag X.Y.Z (e.g., 2.7.0).
    • The release process includes:
      • Linting, unit tests, and BDD tests
      • Code coverage updates
      • Image builds with the specific tag (e.g., 2.7.0)
      • Helm chart updates and publishing

  3. Post-GA Version Increments:

    • After the release is GA (General Availability):
      • The next pre-release version (2.7.1-prerelease) is published.
      • The develop branch continues with 2.8.0-develop for the next major/minor release cycle.

Patch Release Process

  1. Branching & Changes:

    • Patch releases are made against the existing release branch (e.g., release/2.7).
    • All merged changes are available for testing via the prerelease version (2.7.1-prerelease).

  2. Final Patch Release Creation:

    • When ready, the repo owner creates a release with tag X.Y.Z+1 (e.g., 2.7.1).
    • The release process includes:
      • Linting, unit tests, and BDD tests
      • Code coverage updates
      • Image builds with the specific tag (e.g., 2.7.1)
      • Helm chart updates and publishing

  3. Post-GA Version Increments:

    • Once the patch is GA:
      • The next pre-release version (2.7.2-prerelease) is published.
      • The develop branch continues with 2.8.0-develop for the next major/minor release cycle.

Release Artifacts

Before finalizing a release or patch release, it is ensured that all significant changes are documented in CHANGELOG.md.

This document streamlines the release process it ensuring all necessary details remain intact.