LTS roadmap

This page is the honest answer to "how long do you support a given release?" Short form today: rolling releases on the trunk, no LTS branch, best-effort community support. The longer form covers the v2+ LTS plan, the support-tier dependency, and the concrete cadence ISVs can plan against if they're stitching Pleach into a multi-year product roadmap.

Today — rolling releases on trunk

@pleach/* ships from a single trunk (vine). Minor versions ship roughly monthly; patches ship as needed, sometimes multiple per week during active development. There is no v1.x LTS branch.

What this means in practice for ISVs:

• You pin a specific version range in your package.json. Standard semver-range behavior — ^1.0.0 picks up minor + patch updates, ~1.2.0 picks up patch only, 1.2.3 freezes.
• Patch versions are additive and non-breaking by policy. Per docs/pack-117-per-sku-semver-policy.md in the repo, patch releases never introduce breaking changes. ISVs pinning at ~1.x.y granularity get security and bug fixes without surface drift.
• Minor versions are additive on the public surface. Internal refactors and new features can land, but the public exports declared in package.json:exports stay back-compat. Minor-version pins (^1.2.0) are the recommended floor for most ISV embeddings.
• Major versions can change the public surface. Major cuts are rare (the first major was 1.0.0); they're coordinated across SKUs per the per-SKU semver policy.

Support today is community-driven: GitHub issues, README + docs site at getpleach.com, the public-facing docs you're reading now. Maintainers respond as bandwidth allows. There is no SLA.

If that posture is acceptable for your product, you can build against trunk today. The redistribution rights page covers the LICENSE side.

Why no LTS today

LTS branches are not a documentation deliverable — they're an organizational commitment. A real LTS branch means:

• Backport automation that picks security and critical-bug patches from trunk onto an lts-v1.x branch.
• A dedicated changelog and security-advisory channel for the LTS branch.
• A support team capable of triaging customer-reported bugs against an LTS-branch reproduction (which often differs from trunk).
• A CVE-tracking process with named owners who can ship a signed patch on a 24h window when a security disclosure lands.

Pleach's bootstrap-stage organization (small core team, no dedicated support engineers) cannot credibly commit to any of those four today. Announcing an LTS branch without the underlying organization to support it would be worse than the current "trunk + community support" honesty — it'd be a promise ISVs would make commitments against and we'd then break.

The v1 framing is therefore preservation-only: build the substrate that makes LTS possible in v2 (wire-format stability protocol, semver discipline, audit gates that catch breaking changes), but don't ship the LTS branch itself.

What v1 already locks in to make LTS possible later

Three v1 substrates are LTS prerequisites and they're already in place:

• Wire-format stability protocol (C11). The protocol for bumping any wire format the runtime emits or consumes — event log shape, checkpoint shape, stream-event taxonomy. Every breaking-shape change ships behind a compat shim, never a hard cut. Tracked in 03-core-changes/C11-wire-format-bump-protocol.md in the design pack.
• Per-SKU semver discipline. Each @pleach/* SKU versions independently; a major bump in one SKU doesn't cascade through the cohort. Documented at docs/pack-117-per-sku-semver-policy.md in the repo. This matters for LTS because backporting a fix from @pleach/core trunk into @pleach/core@1.x doesn't require coordinating with every other SKU's release cycle.
• audit:sku-license-fsl-lock and the gate cohort. The pre-merge gates that catch LICENSE / package-shape / export-surface drift run on every PR. This is the infrastructure that makes "LTS branch with backported fixes" a non-chaotic exercise — every backport candidate runs through the same gate matrix that protects trunk.

If you're an ISV planning a multi-year product roadmap and the question is "will Pleach not break my product without warning?", these three substrates are the v1 commitment we can honor today.

v2+ — the LTS branch plan

The v2+ scope for LTS:

• Annual LTS cuts. Each calendar year, one minor version is designated as the LTS for that year — for example, @pleach/core@1.x where x is the LTS-designated minor.
• 24-month security backport window. Once a version is LTS-designated, security fixes and critical bug fixes are backported to that branch for 24 months. Feature work does not backport.
• Overlapping LTS windows. At any point in time, at most two LTS branches are active (the current LTS and the previous LTS during its grace window). ISVs always have a supported upgrade path that doesn't require jumping more than one LTS at a time.
• Documented end-of-life dates. Every LTS cut publishes its EOL date at the time it's cut. No surprise sunsets.

The cadence above is the working plan, not a binding promise. The plan ships when:

1. A support organization exists at Pleach to backport, triage, and respond to LTS-branch customer reports. This is the year-3+ hire scope.
2. There is at least one signed ISV master agreement that covers LTS commitments. ISV demand drives the LTS investment; we don't ship a paid-support tier on speculation.

Until both of those are true, the v2+ LTS plan is published intent, not a contract.

v2+ — the support tier

LTS is half the story. The other half is paid support — a contract that gives ISVs named contacts, an escalation path, and SLA-backed response times. The v2+ scope:

• A support team of roughly 3-5 engineers, hired and trained on the Pleach internals.
• A 24/7 escalation runbook covering security disclosures, production-down incidents, and contract-bound performance issues.
• An SLA tracker that measures actual response times against contract commitments and reports them quarterly.
• A customer portal (likely; not committed) for ticket tracking, status updates, and runbook access.

The economics are concrete: ~$500K–$2M/year of investment to maintain a credible support organization at that scale. Bootstrap revenue does not fund that investment; the investment fires only after sufficient signed-contract revenue is in hand to justify it.

If you're an ISV who needs 24/7 paid support today, the v1 posture is "we can't credibly offer that yet." If your embedded product can be built against community-supported trunk for now with an eye toward a paid contract once Pleach stands up the support organization, then v1 is workable and the v2 transition will be smoother for both sides.

What ISVs can plan against today

A practical summary of what an ISV planning a multi-year embedded-Pleach product roadmap can commit to:

• Today through v2+ cutover. Pin a specific semver range per SKU (^1.x is the safe default for most embeddings). Watch CHANGELOG entries on each SKU. Upgrade on your schedule.
• Wire formats are stable across minor bumps. The C11 protocol guarantees compat shims for any wire-format change. Persistent state — event log rows, checkpoints, audit records — survives upgrades.
• Security fixes ship as patches. Even in the pre-LTS-branch era, security disclosures get patch releases.
• No surprise license cuts. FSL-1.1-Apache-2.0 across the cohort, locked by audit:sku-license-fsl-lock on every PR. The Apache 2.0 transition at +2 years is automatic via the future-license clause.
• An LTS branch is roadmap, not committed. Build your product against the assumption that you'll need to upgrade minor versions periodically; treat any future LTS branch as a bonus that reduces upgrade pressure.

Related pages