-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: Add RELEASE.md for the release process #1690
base: main
Are you sure you want to change the base?
Conversation
docs: update README for version compatibility Signed-off-by: Kemal Akkoyun <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM, just had some questions :)
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean with our personal accounts? Or Prometheus account?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you just clarify that we don't have a cadence before merging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Some comments (:
|
||
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also not needed?
docs: update README for version compatibility
fixes #1681
Signed-off-by: Kemal Akkoyun [email protected]