docs: refactor RELEASE

Signed-off-by: Abhinandan Purkait <purkaitabhinandan@gmail.com>

RELEASE.md

@@ -1,36 +1,84 @@
 # Release Process
 
-Local PV ZFS tries follows semantic versioning principles as specified here https://semver.org. It tries to follows a 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](https://github.com/orgs/openebs/projects/78).
+Local PV ZFS follows [semantic versioning](https://semver.org) 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](https://github.com/orgs/openebs/projects/78).
 
 ## 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
-- Regression and Feature Verification Automated tests
-- Exploratory testing by QA engineers
-- Strict security scanners on the container images
-- Upgrade from previous releases
-- Beta testing by users on issues that they are interested in
+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:
 
-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.
+- 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
 
-Once all the above tests are completed, a main release is created.
+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 with container images and a respective helm chart as the only recommended way of installation. Even though the [zfs-operator](./deploy/zfs-operator.yaml) is also published, it is generated by templating the helm chart itself.
+Local PV ZFS is released as container images and a corresponding Helm chart, which is the recommended installation method. Although the [zfs-operator](./deploy/zfs-operator.yaml) 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
 
-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`.
+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.
 
-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.
+## Release Artifacts
 
-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`.
+- **Container Images:** Published at [Docker Hub](https://hub.docker.com/r/openebs/zfs-driver/tags)
+- **Helm Charts:** Hosted on [GitHub Deployments](https://github.com/openebs/zfs-localpv/tree/gh-pages)
 
-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.
+Before finalizing a release or patch release, it is ensured that **all significant changes** are documented in `CHANGELOG.md`.
 
-The helm charts are hosted on github deployments for the corresponding releases.
+---
 
-The tagged images are published at: <https://hub.docker.com/r/openebs/zfs-driver/tags>
-The release Helm charts are published at: <https://github.com/openebs/zfs-localpv/tree/gh-pages>
+This document streamlines the release process it ensuring all necessary details remain intact.
 
-It should be verified if all significant changes to the project have been itemized on to the CHANGELOG.md file, before a release is cut.