docs: Add RELEASE.md for the release process #1690
Conversation
docs: update README for version compatibility Signed-off-by: Kemal Akkoyun <[email protected]>
| @@ -0,0 +1,152 @@ | |||
| # Release | |||
|
|
|||
| The Prometheus Go client library follows a release process similar to the [Prometheus server](https://github.com/prometheus/prometheus/blob/main/RELEASE.md). | |||
There was a problem hiding this comment.
Is it similar? I have the impression that we do releases when we have a feeling it's needed, there's no schedule here 🤔
There was a problem hiding this comment.
I can explicitly state that we don't have a cadence.
| 8. Announce release: | ||
| - <[email protected]> | ||
| - Slack | ||
| - x.com/BlueSky |
There was a problem hiding this comment.
Do you mean with our personal accounts? Or Prometheus account?
There was a problem hiding this comment.
I don't think it matters. We can use our own accounts and ask someone to repost it.
There was a problem hiding this comment.
I don't think it matters. We can use our own accounts and ask someone to repost it.
|
|
||
| - Maintain separate `release-<major>.<minor>` branches | ||
| - Branch protection enabled automatically for `release-*` branches | ||
| - Bug fixes go to latest release branch, then merge to main |
There was a problem hiding this comment.
| - Bug fixes go to latest release branch, then merge to main | |
| - Bug fixes go to the latest release branch, then merge to main |
| - Branch protection enabled automatically for `release-*` branches | ||
| - Bug fixes go to latest release branch, then merge to main | ||
| - Features and changes go to main branch | ||
| - Older release branches maintained on best-effort basis |
There was a problem hiding this comment.
| - 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 |
|
|
||
| 1. Review main branch state: | ||
| - Expedite critical bug fixes | ||
| - Hold back risky changes |
There was a problem hiding this comment.
| - Hold back risky changes | |
| - Don't rush on risky changes, consider them for the next release if not ready |
| 1. Review main branch state: | ||
| - Expedite critical bug fixes | ||
| - Hold back risky changes | ||
| - Update dependencies via Dependabot PRs |
There was a problem hiding this comment.
| - Update dependencies via Dependabot PRs | |
| - Update dependencies via Dependabot PRs or manually if needed |
| git push origin release-<major>.<minor> | ||
| ``` | ||
|
|
||
| 2. Create feature branch: |
There was a problem hiding this comment.
| 2. Create feature branch: | |
| 2. Create a new branch on top of `release-<major>.<minor>`: |
| 1. **Internal Testing**: | ||
| - Full test suite must pass | ||
| - Integration tests with latest Prometheus server | ||
| - Benchmark comparisons with previous version |
There was a problem hiding this comment.
What do you mean? We don't have any tooling or way right now. Should we skip this and add once we have such a process?
| - Testing with prometheus/prometheus master branch | ||
| - Testing with kubernetes/kubernetes master branch |
There was a problem hiding this comment.
| - Testing with prometheus/prometheus master branch | |
| - Testing with kubernetes/kubernetes master branch | |
| - Testing with prometheus/prometheus main branch | |
| - Testing with kubernetes/kubernetes main branch |
| - Integration tests with latest Prometheus server | ||
| - Benchmark comparisons with previous version | ||
|
|
||
| 2. **External Validation**: |
There was a problem hiding this comment.
| 2. **External Validation**: | |
| 2. **External Validation**: | |
| 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. |
| ### 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 |
There was a problem hiding this comment.
Copy pasta? It's bit trivial and also wrong (we are not v0 version)
| ### 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 |
|
Kind reminder @kakkoyun , would be nice to have it! |
|
Thanks for the reminder. I'll wrap this up |
docs: update README for version compatibility
fixes #1681
Signed-off-by: Kemal Akkoyun [email protected]