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