docs: update README and tidy up docs

CHANGELOG.md

@@ -1,3 +1,17 @@
+v2.6.2 / 2024-09-25
+========================
+* fix(chart): handle trailing slash (/) in csi plugin kubelet directory ([#532](https://github.com/openebs/zfs-localpv/pull/532),[@w3aman](https://github.com/w3aman))
+* fix(chart): remove anti-affinity from csi controller ([#552](https://github.com/openebs/zfs-localpv/pull/552),[@Abhinandan-Purkait](https://github.com/Abhinandan-Purkait))
+
+v2.6.1 / 2024-09-17
+========================
+* ci: enhance pull_request workflow ([#557](https://github.com/openebs/zfs-localpv/pull/557),[@Abhinandan-Purkait](https://github.com/Abhinandan-Purkait))
+* ci: add branch preparation and release CI changes ([#567](https://github.com/openebs/zfs-localpv/pull/567),[@Abhinandan-Purkait](https://github.com/Abhinandan-Purkait))
+* chore: cleanup unused scripts, update make manifests ([#569](https://github.com/openebs/zfs-localpv/pull/569),[@Abhinandan-Purkait](https://github.com/Abhinandan-Purkait))
+* chore: replace CRD with auto-generated copy ([#564](https://github.com/openebs/zfs-localpv/pull/548),[@niladrih](https://github.com/niladrih))
+* chore(deps): update analytics dependency ([#578](https://github.com/openebs/zfs-localpv/pull/578),[@niladrih](https://github.com/niladrih))
+* fix: chart.yaml indentation ([#586](https://github.com/openebs/zfs-localpv/pull/586),[@Abhinandan-Purkait](https://github.com/Abhinandan-Purkait))
+
 v2.6.0 / 2024-07-03
 ========================
 * feat(analytics): add heartbeat pinger ([#548](https://github.com/openebs/zfs-localpv/pull/548),[@niladrih](https://github.com/niladrih))

RELEASE.md

@@ -1,39 +1,37 @@
 # Release Process
-zfs-localpv 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/10).
+LocalPV ZFS follows or 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](https://github.com/orgs/openebs/projects/78).
 
-## Release Candidate Verification Checklist
+## Pre-release Candidate Verification Checklist
 
-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:
+Every release has a pre-release tag that gets created on branch creation, explained further below. This pre-release tag is meant for all the below action items throughout the release process:
 - Platform Verification
-- Regression and Feature Verification Automated tests.
+- 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.
-- Dogfooding on OpenEBS workload and e2e infrastructure clusters.
+- Beta testing by users on issues that they are interested in
 
-If any issues are found during the above stages, they are fixed and a new release candidate builds are generated.
+If any issues are found during the above stages, they are fixed and the prerelease tag is overridden by the newer changes and are up for above action items again.
 
-Once all the above tests are completed, a main release tagged image is published.
+Once all the above tests are completed, a main release is created.
 
 ## Release Tagging
 
-zfs-localpv is released as container image with versioned tag.
+LocalPV 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.
 
-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 `v.0.7.x` if release is for 0.7.0.
+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`.
 
-Once the release branch is created, changelog from `changelogs/unreleased` needs to be moved to release specific folder, if release branch is `v0.7.x` then folder will be `changelogs/v0.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` tags are pushed to respective docker registries and also the respective helm charts against these tags 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 is either "Release-Name-RC1" or "Release-Name" depending on whether the tag is a release candidate or a release. (Example: 0.7.0-RC1 is a GitHub release tag for zfs-localpv release candidate build. 0.7.0 is the release tag that is created after the release criteria are satisfied by the zfs-localpv builds.)
+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 tags are `X.Y.Z-prerelease` and `X.Y+1.0-develop`.
 
-Once the release is triggered, Travis build process has to be monitored. Once Travis build 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.
+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.
 
-Images are published at following location :
+The helm charts are hosted on github deployments for the corresponding releases.
 
-https://quay.io/repository/openebs/zfs-driver?tab=tags
-https://hub.docker.com/r/openebs/zfs-driver/tags
+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/LocalPV ZFS/tree/gh-pages
 
-Once a release is created, update the release description with the changelog mentioned in `changelog/v0.7.x`. Once the changelogs are updated in the release, the repo owner needs to create a PR to `develop` with the following details:
-1. update the changelog from `changelog/v0.7.x` to `zfs-localpv/CHANGELOG.md`
-2. If a release is not an RC tag then PR should include the changes to remove `changelog/v0.7.x` folder.
-3. If a release is an RC tag then PR should include the changes to remove the changelog from `changelog/v0.7.x` which are already mentioned in `zfs-localpv/CHANGELOG.md` as part of step number 1.
+Once a release is created:-
+1. The repo owner updates the release page changelog with the necessary contents.
+2. The repo owner updates the [CHANGELOG.md](./CHANGELOG.md) file with the changelog for the release.