Version 3.3.13 home Download and build Libraries and tools Metrics Branch management Demo Discovery service protocol etcd release guide Frequently Asked Questions (FAQ) Logging conventions Production users Reporting bugs Tuning Benchmarks Benchmarking etcd v2.1.0 Benchmarking etcd v2.2.0 Benchmarking etcd v2.2.0-rc Benchmarking etcd v2.2.0-rc-memory Benchmarking etcd v3 Storage Memory Usage Benchmark Watch Memory Usage Benchmark Developer guide etcd API Reference etcd concurrency API Reference Experimental APIs and features gRPC naming and discovery Interacting with etcd Set up a local cluster System limits Why gRPC gateway etcd v3 API Learning etcd client architecture Client feature matrix Data model etcd v3 authentication design etcd versus other key-value stores etcd3 API Glossary KV API guarantees Learner Operations guide Clustering Guide Configuration flags Design of runtime reconfiguration Disaster recovery etcd gateway Failure modes gRPC proxy Hardware recommendations Maintenance Migrate applications from using API v2 to API v3 Monitoring etcd Performance Role-based access control Run etcd clusters inside containers Runtime reconfiguration Supported systems Transport security model Versioning Platforms Amazon Web Services Container Linux with systemd FreeBSD Upgrading Upgrade etcd from 2.3 to 3.0 Upgrade etcd from 3.0 to 3.1 Upgrade etcd from 3.1 to 3.2 Upgrade etcd from 3.2 to 3.3 Upgrade etcd from 3.3 to 3.4 Upgrade etcd from 3.4 to 3.5 Upgrading etcd clusters and applications

Guide

  • New development occurs on the master branch.
  • Master branch should always have a green build!
  • Backwards-compatible bug fixes should target the master branch and subsequently be ported to stable branches.
  • Once the master branch is ready for release, it will be tagged and become the new stable branch.

The etcd team has adopted a rolling release model and supports two stable versions of etcd.

Master branch

The master branch is our development branch. All new features land here first.

To try new and experimental features, pull master and play with it. Note that master may not be stable because new features may introduce bugs.

Before the release of the next stable version, feature PRs will be frozen. A release manager will be assigned to major/minor version and will lead the etcd community in test, bug-fix and documentation of the release for one to two weeks.

Stable branches

All branches with prefix release- are considered stable branches.

After every minor release (http://semver.org/), we will have a new stable branch for that release, managed by a patch release manager. We will keep fixing the backwards-compatible bugs for the latest two stable releases. A patch release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.

© etcd Authors 2020 | Documentation Distributed under CC-BY-4.0

© 2020 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks.
For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

Branch management