|LTS Status||Release||Active LTS Start||Active LTS End/Maintenance Start||Maintenance End|
New semver-major releases of Echo are cut from
master every six months.
New even-numbered versions (e.g. v6, v8, v10, etc) are cut in April. New
odd-numbered versions (e.g. v5, v7, v9) are cut in October.
When a new odd-numbered major release is cut, the previous even-numbered major version transitions to the Long Term Support plan.
Every major version covered by the LTS plan will be actively maintained for a period of 18 months from the date it enters LTS coverage. Following those 18 months of active support, the major version will transition into “maintenance” mode for 12 additional months.
Given this schedule, there will be no more than two active LTS releases at any given time, overlapping for a maximum period of six months.
Once a major version enters LTS coverage, new features (semver-minor) may only be landed with consent of the LTS Working Group. No semver-major changes other than those required for critical security fixes may be landed.
Changes in an LTS-covered major version are limited to:
- Bug fixes;
- Security updates;
- Non-semver-major updates;
- Relevant documentation updates;
- Certain performance improvements where the risk of breaking existing applications is minimal;
- Changes that introduce large amount of code churn where the risk of breaking existing applications is low and where the change in question may significantly ease the ability to backport future changes due to the reduction in diff noise.
Generally changes are expected to live in a Current release for at least 2 weeks before being backported. It is possible for a commit to land earlier at the discretion of the LTS Working Group and the maintainers of the LTS branches.
Once a release moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.
Note that while it is possible that critical security and bug fixes may lead to semver-major changes landing within an LTS stream, such situations will be rare and will land as semver-minor bumps in the LTS covered version.
LTS Staging Branches
Every LTS major version has two branches in the GitHub repository: a release branch and a staging branch. The release branch is used to cut new releases. Only members of the release team should land commits into the release branch. The staging branch is used to land cherry-picked or backported commits from master that need to be included in a future release.
For example, for Echo v2, there is a
v2.x branch and a
branch. When commits land in master that must be cherry-picked for a future
Echo v2 release, those must be landed into the
v2.x-staging branch. When
commits are backported for a future Echo v2 release, those must come in the
form of pull requests opened against the
v2.x-staging branch. Commits are
only landed in the
v2.x branch when a new
v2.x release is being prepared.