Support Lifecycle Schedule¶
Published lifecycle calendar — instantiates Compatibility Management
A published calendar of dates — when a version stops getting fixes, when it is deprecated, when it is removed, and how to request an exception — so dependents can plan their move instead of being surprised.
A Support Lifecycle Schedule is the public, dated commitment covering a version's whole life: when full support narrows to security-only, when the version is formally deprecated, when it reaches end-of-support and is removed, and how a dependent who cannot move in time can request an exception. Its defining move is to turn compatibility promises into calendar dates that dependents can plan against. It answers "supported until when?" and "then what?" — not "what is compatible?" That is what makes a support window finite and legible by default, rather than a version that is quietly "supported until we stop."
Example¶
A national tax authority is retiring an old version of a business filing form as the rules behind it change. Instead of switching one day without warning, it publishes a lifecycle schedule. The old form is accepted through the end of the current filing season (the support window). A deprecation notice names the replacement form and opens an overlap period during which both are accepted. A hard date follows, after which only the new form is processed. And a documented hardship-waiver path lets specific filers — say, those whose accounting software has not yet updated — apply for a one-season extension.
The outcome is that filers, preparers, and software vendors align their own timelines to the published dates and move in an orderly way. The schedule is doing familiar work — the same shape as a software vendor's end-of-life (EOL) calendar or a long-term-support track — but the point is general: without the published dates, the switch either drags on indefinitely or lands as a nasty mid-season surprise.
How it works¶
- Fix dated milestones per version. Set concrete dates for general-support end, the security-only phase, the deprecation announcement, and end-of-support/removal — and, where offered, extended support.
- Publish ahead and commit. The dates are announced in advance and treated as a promise dependents can plan around, not a rolling "maybe" that moves with convenience.
- Point each end date at its successor. Every milestone names the replacement and the migration pointer, so the schedule says not only "this ends" but "move to that by then."
- Govern the exceptions. A defined waiver route with its own criteria and deadline gives genuinely stuck dependents a path, instead of ad-hoc pleading that quietly becomes the norm.
What distinguishes it from its siblings is that it is the temporal artifact — dates and their governance — and not the compatibility rule itself or the how-to of moving.
Tuning parameters¶
- Window length — how long each version stays supported. Longer windows protect slow movers but multiply the versions you must keep alive at once; shorter windows cut carrying cost but push dependents harder.
- Notice lead time — how far ahead deprecation is announced before removal. Generous lead lets dependents plan; short notice frees the provider faster but breaks trust and strands laggards.
- Support tiers — whether support steps down (full → security-only → none) or ends in a single cliff. Tiers soften the ramp but complicate the promise; a single cliff is simpler but harsher.
- Cadence predictability — a fixed calendar (every release supported N months; a long-term track every k releases) versus per-version ad-hoc dates. A fixed cadence lets dependents plan years out; ad-hoc dates flex to reality but cannot be planned against.
- Waiver strictness — how freely extensions are granted. Lenient waivers protect stragglers but erode the schedule's credibility as everyone comes to expect one; strict waivers keep the deadline real but can strand the genuinely stuck.
When it helps, and when it misleads¶
Its strength is that it replaces "supported until we quietly stop" with dates a whole ecosystem can coordinate around: it makes a support window finite by default, names the successor for each ending, and gives hard cases a governed exception path rather than politics.
Its central failure mode is that a published date is worth only its credibility. Extend the removal date again and again and the schedule trains everyone to ignore it — deadlines that always slip coordinate nothing, and the old version becomes de facto immortal, the very "endless legacy by default" a support window exists to prevent. The honest guard is a sunset provision[n1]: a default expiry that takes effect unless a deliberate, justified renewal is made, so the burden falls on extending support, not on ending it. The opposite failure is a schedule set for the provider's convenience with too little notice, stranding dependents who reasonably relied on the old version; the guard there is committed lead times and a real waiver path. And dates say nothing about whether migration is actually feasible by them — paired with a migration path, a schedule coordinates; without one, it is just pressure.
How it implements the components¶
support_window— it sets and publishes the dated window each version is supported, and, via a sunset default, keeps that window finite rather than open-ended.deprecation_policy— it governs retirement as a dated sequence — notice, deprecation, end-of-support, removal — each milestone naming its successor.exception_and_waiver_path— it defines the route, criteria, and deadline for requesting an extension when a dependent genuinely cannot move in time.
It does not state which versions are actually compatible — that rule is Backward Compatibility Policy's — nor lay out how to move between them (Migration Guide), nor perform the move (Rolling Upgrade, Schema Migration). The schedule fixes the *when and the successor; other mechanisms supply the what and the how.*
Related¶
- Instantiates: Compatibility Management — the schedule is the archetype's clock: it commits, in dates, how long coexistence lasts and when it ends.
- Consumes: Backward Compatibility Policy defines what "supported" means; the schedule dates the life of that guarantee.
- Sibling mechanisms: Migration Guide · Backward Compatibility Policy · Rolling Upgrade · Schema Migration · Compatibility Matrix · Adapter Layer · API Versioning · Compatibility Test Suite · Semantic Versioning · Protocol Negotiation
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Support Lifecycle Schedule is defined in the frozen evidence as: A published calendar of dates — when a version stops getting fixes, when it is deprecated, when it is removed, and how to request an exception — so dependents can plan their move instead of being surprised. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Assessment, Review & Assurance — Assessment, Review & Assurance can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Published support phases and end dates descend from software product lifecycle practice.
Related originating lineages:
- Communication & Media Studies — Communication and media research supplies a parallel or contributing lineage for the mechanism's defining operation: a published calendar of dates — when a version stops getting fixes, when it is deprecated, when it is removed, and how to request an exception — so dependents can plan their move….
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: a published calendar of dates — when a version stops getting fixes, when it is deprecated, when it is removed, and how to request an exception — so dependents can plan their move….
- Organizational & Management Science — Service portfolios schedule staffing and retirement.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
"Still supported" is not the same as "still compatible." A version can sit inside its support window yet already be behind a breaking-change boundary for some dependents, and a version out of support can remain perfectly compatible for years. The schedule times support — the provider's commitment to fix and maintain — not the compatibility relation itself, which is Backward Compatibility Policy's to state.
[n1] A sunset provision sets a fixed expiry on a rule, product, or support commitment that takes effect automatically unless it is deliberately renewed — putting the default on ending and the burden of justification on continuing. Borrowed from legislation (sunset clauses), it is the standard guard against a support window quietly becoming permanent. ↩