Cut release v0.4.0-rc.1

Signed-off-by: Bartek Plotka <[email protected]>

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
 

VERSION

@@ -1 +1 @@
-0.4.0-rc.0
+0.4.0-rc.1

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<major>.<minor+1>.0-rc.0`
+1. If after 3 work days there is no major bug, release `v<major>.<minor>.0`
+1. If within 3 work days there is major bug, let's triage it to fix it and then release `v<major>.<minor>.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-<major>.<minor>` 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.