Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

kakkoyun
Copy link
Member

@kakkoyun kakkoyun commented Nov 19, 2024

docs: update README for version compatibility

fixes #1681

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

docs: update README for version compatibility

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

@ArthurSens ArthurSens left a 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).
Copy link
Member

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 🤔

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member

@ArthurSens ArthurSens left a 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?

Copy link
Member

@bwplotka bwplotka left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Update dependencies via Dependabot PRs
- Update dependencies via Dependabot PRs or manually if needed

git push origin release-<major>.<minor>
```

2. Create feature branch:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Member

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?

Comment on lines +134 to +135
- Testing with prometheus/prometheus master branch
- Testing with kubernetes/kubernetes master branch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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**:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Comment on lines +138 to +143
### 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
Copy link
Member

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)

Comment on lines +145 to +152
### 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not needed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a RELEASE.md
3 participants