We use *breaking* word for marking changes that are not backward compatible (relates only to v0.y.z releases.)

Next Thanos release adding support to new discovery method, gRPC mTLS and two new object store providers (Swift and Azure).

Note lots of necessary breaking changes in flags that relates to bucket configuration.

- *breaking*: Removed all bucket specific flags as we moved to config files:

- *breaking*: Removed support of those environment variables for bucket:

- *breaking*: Removed provider specific bucket metrics e.g `thanos_objstore_gcs_bucket_operations_total` in favor of of generic bucket operation metrics.

- *breaking*: Added `thanos_` prefix to memberlist (gossip) metrics. Make sure to update your dashboards and rules.

- S3 provider:

- Set `"X-Amz-Acl": "bucket-owner-full-control"` metadata for s3 upload operation.

- Support for heterogeneous secure gRPC on StoreAPI.

- Handling of scalar result in rule node evaluating rules.

- Flag `--objstore.config-file` to reference to the bucket configuration file in yaml format. Detailed information can be found in document [storage](docs/storage.md).

- File service discovery for StoreAPIs:

- In `thanos rule`, static configuration of query nodes via `--query`

- In `thanos rule`, file based discovery of query nodes using `--query.file-sd-config.files`

- In `thanos query`, file based discovery of store nodes using `--store.file-sd-config.files`

- `/-/healthy` endpoint to Querier.

- DNS service discovery to static and file based configurations using the `dns+` and `dnssrv+` prefixes for the respective lookup. Details [here](/docs/thanos_service_discovery.md)

- `--cluster.disable` flag to disable gossip functionality completely.

- Hidden flag to configure max compaction level.

- Azure Storage.

- OpenStack Swift support.

- Thanos Ruler `thanos_rule_loaded_rules` metric.

- Option for JSON logger format.

- Issue whereby the Proxy Store could end up in a deadlock if there were more than 9 stores being queried and all returned an error.

- Ruler tracing causing panics.

- GatherIndexStats panics on duplicated chunks check.

- Clean up of old compact blocks on compact restart.

- Sidecar too frequent Prometheus reload.

- `thanos_compactor_retries_total` metric not being registered.

- Move handling of HA alertmanagers to be the same as Prometheus.

0.2.0

This page describes the release 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)

We aim for *at least* 1 release per 6 weeks. However, no strict dates are planned.

No release candidates are required until major version.

Additionally we aim for `master` branch being stable.

Process of cutting a new *minor* Thanos release:

1. Add PR on branch `release-<major>.<minor>` that will start minor release branch and prepare changes to cut release.

1. Bump [VERSION file](./VERSION)

1. Update [CHANGELOG file](./CHANGELOG.md)

Note that `CHANGELOG.md` should only document changes relevant to users of Prometheus, 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`.

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.

1. In case of `v0.y.z`, document all incompatibilities in changelog.

1. After review, merge the PR and immediately after this create a `<ver>` release on GitHub `release` page. Describe release and post relevant entry from changelog. Click `Save Draft`. This will trigger CircleCI that builds artifacts. Once tarballs are published on release page, you can click `Publish` and release is complete. Announce `#thanos` slack channel.

We use [Semantic Versioning](http://semver.org/).

NOTE: We have a separate branch for each minor release, named `release-<major>.<minor>`, e.g. `release-0.1`, `release-0.2`. but they are

*NOT* maintained as we don't have major version yet.

The following changes to the above procedures apply:

* In line with [Semantic Versioning](http://semver.org/), append something like `-rc.0` to the version (with the corresponding changes to the tag name, the release name etc.).

* Tick the `This is a pre-release` box when drafting the release in the Github UI.

* Still update `CHANGELOG.md`, but when you cut the final release later, merge all the changes from the pre-releases into the one final update.