go.etcd.io/etcd@v3.3.27+incompatible/Documentation/branch_management.md (about) 1 --- 2 title: Branch management 3 --- 4 5 ## Guide 6 7 * New development occurs on the [master branch][master]. 8 * Master branch should always have a green build! 9 * Backwards-compatible bug fixes should target the master branch and subsequently be ported to stable branches. 10 * Once the master branch is ready for release, it will be tagged and become the new stable branch. 11 12 The etcd team has adopted a *rolling release model* and supports two stable versions of etcd. 13 14 ### Master branch 15 16 The `master` branch is our development branch. All new features land here first. 17 18 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. 19 20 Before the release of the next stable version, feature PRs will be frozen. A [release manager](./dev-internal/release.md#release-management) 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. 21 22 ### Stable branches 23 24 All branches with prefix `release-` are considered _stable_ branches. 25 26 After every minor release (http://semver.org/), we will have a new stable branch for that release, managed by a [patch release manager](./dev-internal/release.md#release-management). 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. 27 28 [master]: https://github.com/coreos/etcd/tree/master