Skip to content
Back to Maintenance & LTS

End-of-Life (EOL)

Declare and communicate the end of support for a version, with a clear upgrade path and a grace period.

Why

EOL is inevitable — you can't support every version forever — but an unmanaged EOL is a breach of trust: users on v16 discover they're unsupported when a critical CVE isn't fixed, and they never had a chance to upgrade. A managed EOL is a communicated event: the EOL date is stated at release ("v16 EOL 2024-04-01"), reminded 6 months and 1 month before, and on the date the version gets a final security patch + a deprecation header pointing to the upgrade path. The grace period — continuing to backport critical security fixes for 3-6 months after EOL for users who are mid-upgrade — is what separates a humane EOL from a cliff. Users who trust your EOL process will adopt your LTS; users who've been burned won't.

When

For every version, at release time (state the EOL date) and at EOL time (execute the communication + final patch).

How

1. At release: state the EOL date in the changelog and the support table (derived from the LTS policy)
2. 6 months before EOL: email all users on that version + blog post "v16 EOL in 6 months — upgrade to v18"
3. 1 month before EOL: escalate — deprecation header on every API response from that version + direct email to laggards
4. On EOL date: ship a final security patch (if any pending) + set deprecation headers + update support table to EOL
5. Grace period (3-6 months): continue backporting CRITICAL security fixes only; communicate that this is the last grace
6. After grace period: no fixes of any kind; the version is truly EOL
7. Keep the EOL version's docs online with a prominent "EOL — upgrade to vX" banner so users aren't stranded

Example

# EOL timeline for v16 (LTS, EOL 2024-04-01)
# Release (2021-10-01): state EOL date
changelog: "v16.0.0 (LTS) — EOL 2024-04-01"

# 6 months before (2023-10-01): email + blog
email(subject: "v16 EOL in 6 months — upgrade to v18")
blog: "v16 reaches end-of-life on 2024-04-01. Upgrade guide: docs/upgrade-v16-v18.md"

# 1 month before (2024-03-01): escalate
app.use((req, res, next) => {
  if (req.appVersion.startsWith('16.')) {
    res.set('Deprecation', 'true');
    res.set('Sunset', 'Mon, 01 Apr 2024 GMT');
  }
  next();
});

# EOL date (2024-04-01): final patch + grace period
changelog: "v16.20.5 (final LTS release) — EOL. Critical security backports continue until 2024-07-01 (grace)."
# After 2024-07-01: no fixes. Docs stay online with banner:
# "v16 is EOL. Upgrade to v18 — docs/upgrade-v16-v18.md"

Common Problems

  • ⚠No EOL date stated at release — users can't plan, and EOL becomes a surprise that breaks trust.
  • ⚠EOL with no grace period — a user mid-upgrade gets zero security fixes during the migration window, which can be months.
  • ⚠Taking EOL docs offline — users who are stuck on the EOL version (can't upgrade immediately) lose their reference and are truly stranded.

Best Practices

  • ✓State the EOL date at release and remind at 6 months and 1 month — users should never be surprised by EOL.
  • ✓Offer a 3-6 month grace period for critical security backports after EOL — this covers users mid-upgrade without committing to indefinite support.
  • ✓Keep EOL docs online with an upgrade banner — stranded users still need reference, and the banner drives them to upgrade.