Skip to content
Back to Maintenance & LTS

LTS Policy

Define which releases are LTS, how long they're supported, and what "support" means (security only vs. bug fixes).

Why

Without an LTS policy, every user question — "will v14 get the security fix?" "how long is v16 supported?" — is answered ad-hoc, inconsistently, and sometimes wrongly. A policy makes support a contract: LTS releases are designated (e.g., every even major), supported for a stated window (e.g., 30 months), with a stated fix scope (security + critical bugs, not new features). This lets enterprise users plan upgrades on their schedule (they can't upgrade every 6 months), and it lets your team allocate maintenance capacity predictably. The policy also prevents the failure mode of supporting every release forever — which is impossible — by making EOL a stated, communicated date, not a slow fade into neglect.

When

Before your first enterprise user asks. Publish the policy in the docs and reference it from every release note.

How

1. Designate LTS releases: e.g., every even major (v16, v18, v20) is LTS; odd majors are "current" only
2. Define the support window: LTS = 30 months from release; current = 6 months
3. Define the fix scope: LTS gets security + critical bug fixes; no new features, no non-critical bugs
4. Define the cadence: LTS gets a patch release every quarter (or on critical CVE)
5. Publish the policy in docs/LTS.md with a support table: version, type, release date, EOL date
6. Communicate EOL 6 months in advance via the same deprecation channels (headers, email, blog)
7. Track adoption: if >20% of users are on an EOL version, extend or communicate harder — don't just cut them off

Example

# docs/LTS.md
## Policy
- LTS: every even major (v16, v18, v20), supported 30 months
- Current: every major, supported 6 months (upgrade path to next LTS)
- Fix scope: LTS gets security + critical bugs only; no new features

## Support table
| Version | Type    | Released   | EOL        | Status   |
|---------|---------|------------|------------|----------|
| v20     | LTS     | 2024-04-01 | 2026-10-01 | active   |
| v19     | current | 2023-10-01 | 2024-10-01 | EOL soon |
| v18     | LTS     | 2022-10-01 | 2025-04-01 | active   |
| v17     | current | 2022-04-01 | 2022-10-01 | EOL      |
| v16     | LTS     | 2021-10-01 | 2024-04-01 | EOL      |

# LTS patch release (quarterly, security + critical only)
# v18.20.1 — backports CVE-2024-1234 fix from v20
# changelog: "v18.20.1 (LTS): security fix for CVE-2024-1234"

Common Problems

  • ⚠Supporting every release forever — impossible, but teams try by never declaring EOL, and maintenance capacity spreads thin across 5 versions.
  • ⚠LTS gets new features — now it's not LTS, it's a fork, and the support window is meaningless because the API keeps changing.
  • ⚠No EOL communication — users discover they're unsupported when a CVE isn't fixed, which is the worst possible way to learn.

Best Practices

  • ✓Publish a support table with EOL dates and reference it from every release note — users should never have to ask "is v18 still supported."
  • ✓LTS means security + critical bugs only, never new features — the moment LTS gets a feature, it's a fork and the policy is broken.
  • ✓Communicate EOL 6 months in advance and track adoption — if >20% are on the EOL version, extend rather than abandon.