Module path renamed github.com/prometheus/common → github.com/hanzoai/common. The only functional patch is config/http_config.go: strip conntrack-based dial-context instrumentation, replace with stdlib net.Dialer. This breaks the transitive chain prometheus/common/config → mwitkow/go-conntrack → prometheus/client_golang/prometheus that was leaking into every consumer of prometheus/common/config (alertmanager notifiers, etc.). Functional impact: HTTP clients built via NewClientFromConfig no longer emit go-conntrack connection-tracking metrics (active/closed counters). The connection count is observable via the underlying http.Transport metrics that luxfi/metric ships, so this is loss-of-observability-zero for callers on the Hanzo/Lux stack.
1.8 KiB
Releases
What to do know before cutting a release
While prometheus/common does not have a formal release process. We strongly encourage you follow these steps:
- Scan the list of available issues / PRs and make sure that You attempt to merge any pull requests that appear to be ready or almost ready
- Notify the maintainers listed as part of
MANTAINERS.mdthat you're going to do a release.
With those steps done, you can proceed to cut a release.
How to cut an individual release
There is no automated process for cutting a release in prometheus/common.
The primary trigger for announcing a release is pushing a new version tag.
NOTE: As soon as a new tag is created, many downstream projects will automatically create pull requests to update their dependency of prom/common. Make sure the release is ready to go, with an updated changelog including notices of any breaking changes, before pushing a new tag.
Here are the basic steps:
- Update CHANGELOG.md, applying the new version number (this time including the
vprefix, e.g.v0.53.0) and date to the changes listed under ``## main / unreleased`, and commit those changes to the main branch. - Use GitHub's release feature via this link to apply a new tag. The tag name must be prefixed with a
ve.g.v0.53.0and then use the "Generate release notes" button to generate the release notes automagically ✨. No need to create a discussion or mark it a pre-release, please do make sure it is marked as the latest release.
Versioning strategy
We aim to adhere to Semantic Versioning as much as possible. For example, patch version (e.g. v0.0.x) releases should contain bugfixes only and any sort of major or minor version bump should be a minor or major release respectively.