Support Tiers

Define tiers (e.g., LTS / current / beta / EOL) so users know what support level they're getting.

Why

A single "supported" boolean is too coarse — it doesn't distinguish a beta (use at your own risk) from an LTS (production-ready, 30-month support) from a current release (supported but upgrade soon). Tiers give users a mental model: they can choose LTS for stability, current for features, or beta for preview, and each tier has a stated support level (fix scope, response time, window). This also lets your team allocate support capacity correctly — LTS gets priority security backports, beta gets best-effort bug reports, EOL gets nothing. Without tiers, every release is treated the same, which means either over-supporting betas (wasted effort) or under-supporting LTS (enterprise users leave).

When

When you have >3 concurrent versions in the wild. Publish the tiers in the docs alongside the LTS policy.

How

1. Define 3-5 tiers: beta (preview, best-effort) | current (supported, upgrade soon) | LTS (stable, 30mo) | EOL (unsupported)
2. For each tier, state: fix scope (security? bugs? features?), response SLA, support window, upgrade expectation
3. Tag every release with its tier in the changelog and the support table
4. Make tier transitions explicit: beta -> current on stable release; current -> LTS on designation; LTS -> EOL on window end
5. Allow users to query the tier programmatically: GET /api/version returns { version, tier, eolDate }
6. Allocate support capacity by tier: LTS gets 60% of maintenance capacity, current 30%, beta 10%, EOL 0%

Example

# Support tiers (in docs/LTS.md)
| Tier    | Fix scope              | SLA       | Window | Upgrade |
|---------|------------------------|-----------|--------|---------|
| beta    | best-effort bugs       | none      | 3mo    | to current |
| current | security + bugs        | 5 days    | 6mo    | to next   |
| LTS     | security + critical    | 2 days    | 30mo   | optional  |
| EOL     | none                   | none      | 0      | required  |

# Programmatic tier query
app.get('/api/version', (req, res) => {
  res.json({
    version: '18.20.1',
    tier: 'LTS',
    eolDate: '2025-04-01',
    supported: true,
  });
});

# Tier transition in changelog
## v20.0.0 (2024-04-01)
- Tier: LTS (designated 2024-04-01, EOL 2026-10-01)
## v19.0.0 (2023-10-01)
- Tier: current -> EOL (2024-10-01) — upgrade to v20

Common Problems

⚠No tier on the release — users can't tell if v19 is safe for production or a beta, so they either over-caution (skip LTS) or under-caution (run beta in prod).
⚠Same support effort for all tiers — beta gets the same bug-fix priority as LTS, wasting capacity that LTS users are paying for.
⚠Tier transitions are silent — v19 becomes EOL with no announcement, and users find out when a CVE isn't backported.

Best Practices

✓Tag every release with its tier in the changelog and a programmatic /api/version endpoint — users should never guess their support level.
✓Allocate support capacity by tier (LTS 60%, current 30%, beta 10%) — this matches what enterprise users pay for.
✓Announce every tier transition (current->EOL, beta->current) in the changelog + email — silent transitions break trust.