Skip to content

RELEASE.md

Latest commit

 

History

History
84 lines (59 loc) · 3.93 KB

RELEASE.md

File metadata and controls

84 lines (59 loc) · 3.93 KB
Raw

Release Process

Local PV ZFS follows semantic versioning principles and aims for a quarterly minor version release cadence. The scope of each release depends on contributor availability and is tracked in the Release Tracker Projects.

Pre-release Candidate Verification Checklist

Each release has a pre-release version, created upon branch creation (explained further below). This pre-release version is used for the following validation steps:

  • 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 arise during these stages, they are fixed, and the pre-release version is updated for further validation. This cycle continues until all tests are successfully completed, after which a main release is created.

Release Tagging

Local PV ZFS is released as container images and a corresponding Helm chart, which is the recommended installation method. Although the zfs-operator is also published, it is generated by templating the Helm chart.

Versioning Format

The release tags follow semantic versioning:

  • Final release tag: X.Y.Z
  • Pre-release version: X.Y.Z-prerelease
  • Development version: X.Y+1.0-develop

Note: The prerelease and develop versions are intermediate versions that get overridden with each change merged into their respective branches. These versions are only for testing and are not associated with any Git tags.

Major/Minor Release Process

  1. Branch Creation:

    • The repo owner creates a release branch from develop, named in the format release/X.Y (e.g., release/2.7 for version 2.7.x).

  2. 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.

  3. 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

  4. 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.