Release v0.9.0

This ends a long time of not really tagging versions (as it didn't
make a lot of sense - we could have tagged every commit with a new
minor release essentially). I still worked through the git log and GH
issues to create a nice CHANGELOG.md.

As dependency management tools really love version tags these days, I
plan to tag more often from now on. The ideas behind the pre-1.0
version numbers are explained in the README.md as changed in this
commit.

I also changed the issue template accordingly.

Signed-off-by: beorn7 <beorn@soundcloud.com>
This commit is contained in:
beorn7 2018-10-15 01:48:21 +02:00
parent 0b47a5c709
commit b2c0ab4f6e
4 changed files with 116 additions and 38 deletions

View File

@ -1,8 +1,30 @@
<!-- <!--
If you are unhappy how your favorite Go dependency management tool deals For bug reports, please provide the version or the Git commit hash for
with this repository, please do not file an issue but read which you have observed the behavior in question.
https://github.com/prometheus/client_golang#important-note-about-releases-versioning-tagging-stability-and-your-favorite-go-dependency-management-tool
instead. Thank you very much. Note that we use GitHub issues for bugs and (uncontroversial) feature
requests (see below for details).
Please do *NOT* ask usage questions in GitHub issues. Usage questions make
most sense on the users mailing list, where more people are available to
potentially respond to your question, and the whole community can benefit
from the answers provided (perhaps your question has already been answered,
search the archive to find out):
https://groups.google.com/forum/#!forum/prometheus-users
While a GitHub issue is fine to track progress on an uncontroversial
feature request, many feature requests touch the best practices and
concepts of Prometheus as a whole and need to be discussed with the wider
developer community first. This is in particular true for a request to
reconsider a prior rejection of a feature request. Those overarching
discussions happen on the developer mailing list (GitHub issues, in
particular closed ones, are not tracked by the wider developer community
and thus inadequate):
https://groups.google.com/forum/#!forum/prometheus-developers
You can find more information at: https://prometheus.io/community/
--> -->

View File

@ -1,3 +1,55 @@
## 0.9.0 / 2018-10-15
* [CHANGE] Go1.6 is no longer supported.
* [CHANGE] More refinements of the `Registry` consistency checks: Duplicated
labels are now detected, but inconsistent label dimensions are now allowed.
Collisions with the “magic” metric and label names in Summaries and
Histograms are detected now. #108 #417 #471
* [CHANGE] Changed `ProcessCollector` constructor. #219
* [CHANGE] Changed Go counter `go_memstats_heap_released_bytes_total` to gauge
`go_memstats_heap_released_bytes`. #229
* [CHANGE] Unexported `LabelPairSorter`. #453
* [CHANGE] Removed the `Untyped` metric from direct instrumentation. #340
* [CHANGE] Unexported `MetricVec`. #319
* [CHANGE] Removed deprecated `Set` method from `Counter` #247
* [CHANGE] Removed deprecated `RegisterOrGet` and `MustRegisterOrGet`. #247
* [CHANGE] API client: Introduced versioned packages.
* [FEATURE] A `Registerer` can be wrapped with prefixes and labels. #357
* [FEATURE] “Describe by collect” helper function. #239
* [FEATURE] Added package `testutil`. #58
* [FEATURE] Timestamp can be explicitly set for const metrics. #187
* [FEATURE] “Unchecked” collectors are possible now without cheating. #47
* [FEATURE] Pushing to the Pushgateway reworked in package `push` to support
many new features. (The old functions are still usable but deprecated.) #372
#341
* [FEATURE] Configurable connection limit for scrapes. #179
* [FEATURE] New HTTP middlewares to instrument `http.Handler` and
`http.RoundTripper`. The old middlewares and the pre-instrumented `/metrics`
handler are (strongly) deprecated. #316 #57 #101 #224
* [FEATURE] “Currying” for metric vectors. #320
* [FEATURE] A `Summary` can be created without quantiles. #118
* [FEATURE] Added a `Timer` helper type. #231
* [FEATURE] Added a Graphite bridge. #197
* [FEATURE] Help strings are now optional. #460
* [FEATURE] Added `process_virtual_memory_max_bytes` metric. #438 #440
* [FEATURE] Added `go_gc_cpu_fraction` and `go_threads` metrics. #281 #277
* [FEATURE] Added `promauto` package with auto-registering metrics. #385 #393
* [FEATURE] Add `SetToCurrentTime` method to `Gauge`. #259
* [FEATURE] API client: Add AlertManager, Status, and Target methods. #402
* [FEATURE] API client: Add admin methods. #398
* [FEATURE] API client: Support series API. #361
* [FEATURE] API client: Support querying label values.
* [ENHANCEMENT] Smarter creation of goroutines during scraping. Solves memory
usage spikes in certain situations. #369
* [ENHANCEMENT] Counters are now faster if dealing with integers only. #367
* [ENHANCEMENT] Improved label validation. #274 #335
* [BUGFIX] Creating a const metric with an invalid `Desc` returns an error. #460
* [BUGFIX] Histogram observations don't race any longer with exposition. #275
* [BUGFIX] Fixed goroutine leaks. #236 #472
* [BUGFIX] Fixed an error message for exponential histogram buckets. #467
* [BUGFIX] Fixed data race writing to the metric map. #401
* [BUGFIX] API client: Decode JSON on a 4xx respons but do not on 204
responses. #476 #414
## 0.8.0 / 2016-08-17 ## 0.8.0 / 2016-08-17
* [CHANGE] Registry is doing more consistency checks. This might break * [CHANGE] Registry is doing more consistency checks. This might break
existing setups that used to export inconsistent metrics. existing setups that used to export inconsistent metrics.

View File

@ -11,7 +11,7 @@ Prometheus HTTP API.
__This library requires Go1.7 or later.__ __This library requires Go1.7 or later.__
## Important note about releases, versioning, tagging, stability, and your favorite Go dependency management tool ## Important note about releases, versioning, tagging, and stability
While our goal is to follow [Semantic Versioning](https://semver.org/), this While our goal is to follow [Semantic Versioning](https://semver.org/), this
repository is still pre-1.0.0. To quote the repository is still pre-1.0.0. To quote the
@ -22,38 +22,42 @@ declaring something 1.0.0 doesn't make it 1.0.0. Instead, we are working
towards a 1.0.0 release that actually deserves its major version number. towards a 1.0.0 release that actually deserves its major version number.
Having said that, we aim for always keeping the tip of master in a workable Having said that, we aim for always keeping the tip of master in a workable
state and for only introducing ”mildly” breaking changes up to and including state. We occasionally tag versions and track their changes in CHANGELOG.md,
[v0.9.0](https://github.com/prometheus/client_golang/milestone/1). After that, but this happens mostly to keep dependency management tools happy and to give
a number of ”hard” breaking changes are planned, see the people a handle they can talk about easily. In particular, all commits in the
[v0.10.0 milestone](https://github.com/prometheus/client_golang/milestone/2), master branch have passed the same testing and reviewing. There is no QA
which should get the library much closer to 1.0.0 state. process in place that would render tagged commits more stable or better tested
than others.
Dependency management in Go projects is still in flux, and there are many tools There is a plan behind the current (pre-1.0.0) versioning, though:
floating around. While [dep](https://golang.github.io/dep/) might develop into
the de-facto standard tool, it is still officially experimental. The roadmap
for this library has been laid out with a lot of sometimes painful experience
in mind. We really cannot adjust it every other month to the needs of the
currently most popular or most promising Go dependency management tool. The
recommended course of action with dependency management tools is the following:
- Do not expect strict post-1.0.0 semver semantics prior to the 1.0.0 - v0.9 is the “production release”, currently tracked in the master
release. If your dependency management tool expects strict post-1.0.0 semver branch. “Patch” releases will usually be just bug fixes, indeed, but
semantics, you have to wait. Sorry. important new features that do not require invasive code changes might also
- If you want absolute certainty, please lock to a specific commit. You can be included in those. We do not plan any breaking changes from one v0.9.x
also lock to tags, but please don't ask for more tagging. This would suggest release to any later v0.9.y release, but nothing is guaranteed. Since the
some release or stability testing procedure that simply is not in place. As master branch will eventually be switched over to track the upcoming v0.10
said above, we are aiming for stability of the tip of master, but if we (see below), we recommend to tell your dependency management tool of choice
tagged every single commit, locking to tags would be the same as locking to to use the latest v0.9.x release, at least for your production software. In
commits. that way, you should get bug fixes and non-invasive, low-risk new features
- If you want to get the newer features and improvements and are willing to without the need to change anything on your part.
take the minor risk of newly introduced bugs and “mild” breakage, just always - v0.10 is a planned release that will have a _lot_ of breaking changes
update to the tip of master (which is essentially the original idea of Go (despite being only a “minor” release in the Semantic Versioning terminology,
dependency management). We recommend to not use features marked as but as said, pre-1.0.0 means nothing is guaranteed). Essentially, we have
_deprecated_ in this case. been piling up feature requests that require breaking changes for a while,
- Once [v0.9.0](https://github.com/prometheus/client_golang/milestone/1) is and they are all collected in the
out, you could lock to v0.9.x to get bugfixes (and perhaps minor new [v0.10 milestone](https://github.com/prometheus/client_golang/milestone/2).
features) while avoiding the “hard” breakage that will come with post-0.9 Since there will be so many breaking changes, the development for v0.10 is
features. currently not happening in the master branch, but in the
[dev-0.10 branch](https://github.com/prometheus/client_golang/tree/dev-0.10).
It will violently change for a while, and it will definitely be in a
non-working state now and then. It should only be used for sneak-peaks and
discussions of the new features and designs.
- Once v0.10 is ready for real-life use, it will be merged into the master
branch (which is the reason why you should lock your dependency management
tool to v0.9.x and only migrate to v0.10 when both you and v0.10 are ready
for it). In the ideal case, v0.10 will be the basis for the future v1.0
release, but we cannot provide an ETA at this time.
## Instrumenting applications ## Instrumenting applications
@ -62,8 +66,8 @@ recommended course of action with dependency management tools is the following:
The The
[`prometheus` directory](https://github.com/prometheus/client_golang/tree/master/prometheus) [`prometheus` directory](https://github.com/prometheus/client_golang/tree/master/prometheus)
contains the instrumentation library. See the contains the instrumentation library. See the
[best practices section](http://prometheus.io/docs/practices/naming/) of the [guide](https://prometheus.io/docs/guides/go-application/) on the Prometheus
Prometheus documentation to learn more about instrumenting applications. website to learn more about instrumenting applications.
The The
[`examples` directory](https://github.com/prometheus/client_golang/tree/master/examples) [`examples` directory](https://github.com/prometheus/client_golang/tree/master/examples)

View File

@ -1 +1 @@
0.8.0 0.9.0