Address review comments

Signed-off-by: Kemal Akkoyun <[email protected]>

Author: kakkoyun

Diff for: RELEASE.md

@@ -1,23 +1,23 @@
 # Release
 
-The Prometheus Go client library follows a release process similar to the [Prometheus server](https://github.com/prometheus/prometheus/blob/main/RELEASE.md).
+The Prometheus Go client library does not follow a strict release schedule. Releases are made based on necessity and the current state of the project.
 
 ## Branch Management
 
 We use [Semantic Versioning](https://semver.org/).
 
 - Maintain separate `release-<major>.<minor>` branches
 - Branch protection enabled automatically for `release-*` branches
-- Bug fixes go to latest release branch, then merge to main
+- Bug fixes go to the latest release branch, then merge to main
 - Features and changes go to main branch
-- Older release branches maintained on best-effort basis
+- Non-latest minor release branches are maintained (e.g. bug and security fixes) on the best-effort basis
 
 ## Pre-Release Preparations
 
 1. Review main branch state:
    - Expedite critical bug fixes
-   - Hold back risky changes
-   - Update dependencies via Dependabot PRs
+   - Don't rush on risky changes, consider them for the next release if not ready
+   - Update dependencies via Dependabot PRs or manually if needed
    - Check for security alerts
 
 ## Cutting a Minor Release
@@ -29,7 +29,7 @@ We use [Semantic Versioning](https://semver.org/).
    git push origin release-<major>.<minor>
    ```
 
-2. Create feature branch:
+2. Create a new branch on top of `release-<major>.<minor>`:
 
    ```bash
    git checkout -b <yourname>/cut-<major>.<minor>.0 release-<major>.<minor>
@@ -61,7 +61,6 @@ We use [Semantic Versioning](https://semver.org/).
 
 7. For Final Release:
    - Wait for CI completion
-   - Verify artifacts published
    - Click "Publish release"
    - For RCs, ensure "pre-release" box is checked
 
@@ -86,8 +85,8 @@ We use [Semantic Versioning](https://semver.org/).
    ```
 
 2. Apply fixes:
-   - Cherry-pick from main: `git cherry-pick <commit>`
-   - Or add new fix commits
+   - Commit the required fixes; avoid refactoring or otherwise risky changes (preferred)
+   - Cherry-pick from main if fix was already merged there: `git cherry-pick <commit>`
 
 3. Follow steps 3-9 from minor release process
 
@@ -102,19 +101,17 @@ If conflicts occur merging to main:
 
 ## Note on Versioning
 
-Go modules require strict semver. Because we don't commit to avoid breaking changes between minor releases, we use major version zero releases for libraries.
-
 ## Compatibility Guarantees
 
 ### Supported Go Versions
 
 - Support provided only for the three most recent major Go releases
-- While the library may work with older versions, no fixes or support provided
+- While the library may work with older Go versions, support and fixes are best-effort for those.
 - Each release documents the minimum required Go version
 
 ### API Stability
 
-The Prometheus Go client library aims to maintain backward compatibility within minor versions, similar to [Go 1 compatibility promises](https://golang.org/doc/go1compat). However, as indicated by the major version zero (v0):
+The Prometheus Go client library aims to maintain backward compatibility within minor versions, similar to [Go 1 compatibility promises](https://golang.org/doc/go1compat):
 
 - API signatures may change between minor versions
 - Types may be modified or relocated
@@ -131,8 +128,8 @@ Before each release:
    - Benchmark comparisons with previous version
 
 2. **External Validation**:
-   - Testing with prometheus/prometheus master branch
-   - Testing with kubernetes/kubernetes master branch
+   - Testing with prometheus/prometheus `main` branch
+   - Testing with kubernetes/kubernetes `main` branch
    - Breaking changes must be documented in CHANGELOG.md
 
 ### Version Policy