Home
benchmarks- dev
- platforms
- rfc
04_to_2_snapshot_migration.md- admin_guide.md
- api.md
- api_v3.md
- auth_api.md
- authentication.md
- backward_compatibility.md
- branch_management.md
- clustering.md
- configuration.md
- discovery_protocol.md
- docker_guide.md
- errorcode.md
- etcd_alert.rules
- etcd_alert.rules.yml
- faq.md
- glossary.md
- internal-protocol-versioning.md
- libraries-and-tools.md
- members_api.md
- metrics.md
- other_apis.md
- production-users.md
- proxy.md
- README.md
- reporting_bugs.md
- runtime-configuration.md
- runtime-reconf-design.md
- security.md
- tuning.md
- upgrade_2_1.md
- upgrade_2_2.md
- upgrade_2_3.md
Table of Contents
This is the documentation for etcd2 releases. Read etcd3 doc for etcd3 releases.
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 one stable version of etcd.
Master branch
The master branch is our development branch. All new features land here first.
If you want to try new 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. We will focus on the testing, bug-fix and documentation 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. We will keep fixing the backwards-compatible bugs for the latest stable release, but not previous releases. The patch release, incorporating any bug fixes, will be once every two weeks, given any patches.