Address review comments

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

Author: kakkoyun

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>
@@ -38,6 +38,7 @@ We use [Semantic Versioning](https://semver.org/).
 3. Update version and documentation:
    - Update `VERSION` file
    - Update `CHANGELOG.md` (user-impacting changes)
+      - Each release documents the minimum required Go version
    - Order: [SECURITY], [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]
    - For RCs, append `-rc.0`
 
@@ -52,18 +53,17 @@ We use [Semantic Versioning](https://semver.org/).
    ```
 
 6. For Release Candidates:
-   - Create PR against prometheus/prometheus using RC version
-   - Create PR against kubernetes/kubernetes using RC version
+   - Create PR against [prometheus/prometheus](https://github.com/prometheus/prometheus) using RC version
+   - Create PR against [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) using RC version
    - Make sure the CI is green for the PRs
    - Allow 1-2 days for downstream testing
    - Fix any issues found before final release
    - Use `-rc.1`, `-rc.2` etc. for additional fixes
+   - For RCs, ensure "pre-release" box is checked
 
 7. For Final Release:
    - Wait for CI completion
-   - Verify artifacts published
-   - Click "Publish release"
-   - For RCs, ensure "pre-release" box is checked
+   - Click "Publish release"!
 
 8. Announce release:
    - <[email protected]>
@@ -86,8 +86,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,21 +102,30 @@ 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
+
+## Minor Version Changes
+- API signatures are `stable` within a **minor** version
+- No breaking changes are introduced
+- Methods may be added, but not removed
+   - Arguments may NOT be removed or added (unless varargs)
+   - Return types may NOT be changed
+- Types may be modified or relocated
+- Default behaviors might be altered (unfortunately, this has happened in the past)
+
+## Major Version Changes
+- API signatures may change between **major** versions
 - Types may be modified or relocated
 - Default behaviors might be altered
 - Feature removal/deprecation can occur with minor version bump
@@ -128,25 +137,27 @@ Before each release:
 1. **Internal Testing**:
    - Full test suite must pass
    - Integration tests with latest Prometheus server
-   - Benchmark comparisons with previous version
+   - (optional) Benchmark comparisons with previous version
+   > There is no facility for running benchmarks in CI, so this is best-effort.
 
 2. **External Validation**:
-   - Testing with prometheus/prometheus master branch
-   - Testing with kubernetes/kubernetes master branch
+
+Test against bigger users, especially looking for broken tests or builds. This will give us awareness of a potential accidental breaking changes, or if there were intentional ones, the potential damage radius of them.
+
+   - Testing with [prometheus/prometheus](https://github.com/prometheus/prometheus) `main` branch
+   - Testing with [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) `main` branch
    - Breaking changes must be documented in CHANGELOG.md
 
 ### Version Policy
 
 - Bug fixes increment patch version (e.g., v0.9.1)
 - New features increment minor version (e.g., v0.10.0)
 - Breaking changes increment minor version with clear documentation
-- Major version remains at 0 to indicate potential instability
 
 ### Deprecation Policy
 
 1. Features may be deprecated in any minor release
 2. Deprecated features:
    - Will be documented in CHANGELOG.md
    - Will emit warnings when used (when possible)
-   - May be removed in next minor version
-   - Must have migration path documented
+