diff --git a/CHANGELOG.md b/CHANGELOG.md index 40eeeab685..bb37f0fd25 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,19 +11,7 @@ We use *breaking* word for marking changes that are not backward compatible (rel ## Unreleased -### Added - -- [#1060](https://github.com/improbable-eng/thanos/pull/1060) Allow specifying region attribute in S3 storage configuration - -### Fixed - -- [#1070](https://github.com/improbable-eng/thanos/pull/1070) Downsampling works back again. Deferred closer errors are now properly captured. - -### Changed - -- [#1073](https://github.com/improbable-eng/thanos/pull/1073) Store: index cache for requests. It now calculates the size properly (includes slice header), has anti-deadlock safeguard and reports more metrics. - -## [v0.4.0-rc.0](https://github.com/improbable-eng/thanos/releases/tag/v0.4.0-rc.0) - 2019.04.18 +## [v0.4.0-rc.1](https://github.com/improbable-eng/thanos/releases/tag/v0.4.0-rc.1) - 2019.04.26 :warning: **IMPORTANT** :warning: This is the last release that supports gossip. From Thanos v0.5.0, gossip will be completely removed. @@ -36,6 +24,7 @@ See [this](docs/proposals/approved/201809_gossip-removal.md) for more details. - [#910](https://github.com/improbable-eng/thanos/pull/910) Query's stores UI page is now sorted by type and old DNS or File SD stores are removed after 5 minutes (configurable via the new `--store.unhealthy-timeout=5m` flag). - [#905](https://github.com/improbable-eng/thanos/pull/905) Thanos support for Query API: /api/v1/labels. Notice that the API was added in Prometheus v2.6. - [#798](https://github.com/improbable-eng/thanos/pull/798) Ability to limit the maximum number of concurrent request to Series() calls in Thanos Store and the maximum amount of samples we handle. +- [#1060](https://github.com/improbable-eng/thanos/pull/1060) Allow specifying region attribute in S3 storage configuration :warning: **WARNING** :warning: #798 adds a new default limit to Thanos Store: `--store.grpc.series-max-concurrency`. Most likely you will want to make it the same as `--query.max-concurrent` on Thanos Query. @@ -121,6 +110,7 @@ Note that this is required to have SRV resolution working on [Golang 1.11+ with - [#868](https://github.com/improbable-eng/thanos/pull/868) Go has been updated to 1.12. - [#1055](https://github.com/improbable-eng/thanos/pull/1055) Gossip flags are now disabled by default and deprecated. - [#964](https://github.com/improbable-eng/thanos/pull/964) repair: Repair process now sorts the series and labels within block. +- [#1073](https://github.com/improbable-eng/thanos/pull/1073) Store: index cache for requests. It now calculates the size properly (includes slice header), has anti-deadlock safeguard and reports more metrics. ### Fixed @@ -136,6 +126,7 @@ Note that this is required to have SRV resolution working on [Golang 1.11+ with - [#982](https://github.com/improbable-eng/thanos/pull/982) Query: now advertises Min & Max Time accordingly to the nodes. - [#1041](https://github.com/improbable-eng/thanos/issues/1038) Ruler is now able to return long time range queries. - [#904](https://github.com/improbable-eng/thanos/pull/904) Compact: Skip compaction for blocks with no samples. +- [#1070](https://github.com/improbable-eng/thanos/pull/1070) Downsampling works back again. Deferred closer errors are now properly captured. ## [v0.3.2](https://github.com/improbable-eng/thanos/releases/tag/v0.3.2) - 2019.03.04 diff --git a/VERSION b/VERSION index fb58cf35c9..cc73c6027e 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.4.0-rc.0 +0.4.0-rc.1 diff --git a/docs/release-process.md b/docs/release-process.md index daf0881683..3ba2b29878 100644 --- a/docs/release-process.md +++ b/docs/release-process.md @@ -1,27 +1,47 @@ -# For maintainers: Releases +# Releases -This page describes the release process for Thanos project. +This page describes the release cadence and process for Thanos project. NOTE: As [Semantic Versioning](http://semver.org/spec/v2.0.0.html) states all 0.y.z releases can contain breaking changes in API (flags, grpc API, any backward compatibility) ## Cadence -We aim for *at least* 1 release per 6 weeks. However, no strict dates are planned. +We aim for regular and strict one release per 6 weeks. 6 weeks is counter from first release candidate to another. +This means that there is no *code freeze* or anything like that. We plan to stick to the exact 6 weeks, so there is no rush +into being within release (except bug fixes). -No release candidates are required until major version. +No feature should block release. -Additionally we aim for `master` branch being stable. +Additionally we (obviously) aim for `master` branch being stable. -## Cutting individual release +## For maintainers: Cutting individual release -Process of cutting a new *minor* Thanos release: +We will choose a release shepherd for each minor release. + +Release shepherd responsibilities: +* Perform releases (from first RC to actual release). +* Announce all releases on all communication channels. + +Process of releasing a *minor* Thanos version: +1. Release `v..0-rc.0` +1. If after 3 work days there is no major bug, release `v..0` +1. If within 3 work days there is major bug, let's triage it to fix it and then release `v..0-rc.++` Go to step 2. +1. Do patch release if needed for any bugs afterwards. Use same `release-xxx` branch. + +### How to release "a version" 1. Add PR on branch `release-.` that will start minor release branch and prepare changes to cut release. + + For release candidate just reuse same branch and rebase it on every candidate until the actual release happens. + 1. Bump [VERSION file](/VERSION) 1. Update [CHANGELOG file](/CHANGELOG.md) Note that `CHANGELOG.md` should only document changes relevant to users of Thanos, including external API changes, performance improvements, and new features. Do not document changes of internal interfaces, code refactorings and clean-ups, changes to the build process, etc. People interested in these are asked to refer to the git history. Format is described in `CHANGELOG.md`. + + The whole release from release candidate `rc.0` to actual release should have exactly the same section. We don't separate + what have changed between release candidates. 1. Double check backward compatibility: 1. *In case of version after `v1+.y.z`*, double check if none of the changes break API compatibility. This should be done in PR review process, but double check is good to have.