You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+36-1Lines changed: 36 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,48 @@
1
+
## 2.7.1 / 2019-01-31
2
+
3
+
This release has a fix for a Stored DOM XSS vulnerability that can be triggered when using the query history functionality. Thanks to Dor Tumarkin from Checkmarx for reporting it.
4
+
5
+
*[BUGFIX/SECURITY] Fix a Stored DOM XSS vulnerability with query history. #5163
6
+
*[BUGFIX]`prometheus_rule_group_last_duration_seconds` now reports seconds instead of nanoseconds. #5153
7
+
*[BUGFIX] Make sure the targets are consistently sorted in the targets page. #5161
8
+
9
+
## 2.7.0 / 2019-01-28
10
+
11
+
We're rolling back the Dockerfile changes introduced in 2.6.0. If you made changes to your docker deployment in 2.6.0, you will need to roll them back. This release also adds experimental support for disk size based retention. To accomodate that we are deprecating the flag `storage.tsdb.retention` in favour of `storage.tsdb.retention.time`. We print a warning if the flag is in use, but it will function without breaking until Prometheus 3.0.
12
+
13
+
*[CHANGE] Rollback Dockerfile to version at 2.5.0. Rollback of the breaking change introduced in 2.6.0. #5122
14
+
*[FEATURE] Add subqueries to PromQL. #4831
15
+
*[FEATURE][EXPERIMENTAL] Add support for disk size based retention. Note that we don't consider the WAL size which could be significant and the time based retention policy also applies. #5109prometheus/tsdb#343
16
+
*[FEATURE] Add CORS origin flag. #5011
17
+
*[ENHANCEMENT] Consul SD: Add tagged address to the discovery metadata. #5001
18
+
*[ENHANCEMENT] Kubernetes SD: Add service external IP and external name to the discovery metadata. #4940
19
+
*[ENHANCEMENT] Azure SD: Add support for Managed Identity authentication. #4590
20
+
*[ENHANCEMENT] Azure SD: Add tenant and subscription IDs to the discovery metadata. #4969
21
+
*[ENHANCEMENT] OpenStack SD: Add support for application credentials based authentication. #4968
22
+
*[ENHANCEMENT] Add metric for number of rule groups loaded. #5090
23
+
*[BUGFIX] Avoid duplicate tests for alert unit tests. #4964
24
+
*[BUGFIX] Don't depend on given order when comparing samples in alert unit testing. #5049
25
+
*[BUGFIX] Make sure the retention period doesn't overflow. #5112
26
+
*[BUGFIX] Make sure the blocks don't get very large. #5112
27
+
*[BUGFIX] Don't generate blocks with no samples. prometheus/tsdb#374
28
+
*[BUGFIX] Reintroduce metric for WAL corruptions. prometheus/tsdb#473
*[BUGFIX] Marathon SD: Use `Tasks.Ports` when `RequirePorts` is `false`. #5026
34
+
*[BUGFIX] Promtool: Fix "out-of-order sample" errors when testing rules. #5069
35
+
1
36
## 2.6.0 / 2018-12-17
2
37
38
+
*[CHANGE] Remove default flags from the container's entrypoint, run Prometheus from `/etc/prometheus` and symlink the storage directory to `/etc/prometheus/data`. #4976
3
39
*[CHANGE] Promtool: Remove the `update` command. #3839
4
40
*[FEATURE] Add JSON log format via the `--log.format` flag. #4876
5
41
*[FEATURE] API: Add /api/v1/labels endpoint to get all label names. #4835
6
42
*[FEATURE] Web: Allow setting the page's title via the `--web.ui-title` flag. #4841
7
43
*[ENHANCEMENT] Add `prometheus_tsdb_lowest_timestamp_seconds`, `prometheus_tsdb_head_min_time_seconds` and `prometheus_tsdb_head_max_time_seconds` metrics. #4888
Copy file name to clipboardExpand all lines: RELEASE.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,26 +1,28 @@
1
1
# Releases
2
2
3
-
This page describes the release process and the currently planned schedule for upcoming releases as well as the respective release schepherds. Release shepards are chosen on a voluntary basis.
3
+
This page describes the release process and the currently planned schedule for upcoming releases as well as the respective release shepherd. Release shepherd are chosen on a voluntary basis.
4
4
5
5
## Release schedule
6
6
7
7
Release cadence of first pre-releases being cut is 6 weeks.
8
8
9
-
| release series | date of first pre-release (year-month-day) | release shepard|
9
+
| release series | date of first pre-release (year-month-day) | release shepherd|
If you are interested in volunteering please create a pull request against the [prometheus/prometheus](https://github.com/prometheus/prometheus) repository and propose yourself for the release series of your choice.
17
19
18
-
## Release shepard responsibilities
20
+
## Release shepherd responsibilities
19
21
20
-
The release shepard is responsible for the entire release series of a minor release, meaning all pre- and patch releases of a minor release. The process starts with the initial pre-release.
22
+
The release shepherd is responsible for the entire release series of a minor release, meaning all pre- and patch releases of a minor release. The process starts with the initial pre-release.
21
23
22
24
* The first pre-release is scheduled according to the above schedule.
23
-
* With the pre-release the release shepard is responsible for running and monitoring a benchmark run of the pre-release for 3 days, after which, if successful, the pre-release is promoted to a stable release.
25
+
* With the pre-release the release shepherd is responsible for running and monitoring a benchmark run of the pre-release for 3 days, after which, if successful, the pre-release is promoted to a stable release.
24
26
* Once a pre-release has been released, the `master` branch of the repository is frozen for any feature work, only critical bug fix work concerning the minor release is merged.
25
27
* Pre-releases are done from `master`, after pre-releases are promoted to the stable release a `release-major.minor` branch is created.
26
28
@@ -36,7 +38,7 @@ We use [Semantic Versioning](http://semver.org/).
36
38
37
39
We maintain a separate branch for each minor release, named `release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`.
38
40
39
-
The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch. Whether merging master back into a release branch makes more sense is left up to the shepard's judgement.
41
+
The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch. Whether merging master back into a release branch makes more sense is left up to the shepherd's judgement.
40
42
41
43
If a bug fix got accidentally merged into master, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into master. Try to avoid that situation.
0 commit comments