End of Life Policy

End of life policy defines when design system versions stop receiving any form of support or updates. Clear policies help consumers understand that older versions will eventually become unsupported, enabling them to plan upgrades before support ends. Well-communicated policies prevent surprises and maintain consumer trust.

What Is End of Life Policy

End of life (EOL) policy specifies when versions transition from supported to unsupported status. After reaching end of life, versions receive no further updates including security fixes. Consumers running EOL versions must upgrade to receive any support or fixes from the design system team.

EOL policies exist because maintaining old versions indefinitely is unsustainable. Team capacity must focus on current development and recently-released versions. EOL policies communicate these practical constraints clearly, helping consumers understand the lifecycle of versions they adopt.

How End of Life Policy Works

EOL policies define criteria for reaching end of life, communicate timelines in advance, and handle the transition period. Consistent application builds consumer confidence in the policy.

Criteria definition establishes when versions reach EOL. Common criteria include time-based rules (versions reach EOL X months after the next major version), version-count rules (only the latest N major versions are supported), or explicit designation (EOL dates are assigned when versions are released).

Timeline communication gives consumers advance notice. Announcing EOL dates well in advance (often six to twelve months) provides migration time. Regular reminders as EOL approaches help consumers who missed initial announcements.

Transition handling manages the actual EOL event. Final communications confirm the version is now unsupported. Documentation may be archived or marked clearly. Support channels decline requests related to EOL versions, directing consumers to upgrade.

Key Considerations

• Define EOL criteria consistently across versions
• Announce EOL dates at least six months in advance
• Send reminder communications as EOL approaches
• Clearly mark documentation for EOL versions
• Direct support requests to upgrade rather than helping with EOL versions

Common Questions

How should teams handle critical security issues in EOL versions?

Security issues in EOL versions create difficult decisions. Strictly following policy means no fixes for EOL versions. However, severe vulnerabilities affecting many consumers may warrant exceptions.

Some teams establish an exception process for critical security issues. If a vulnerability is severe enough (such as remote code execution) and affects a significant consumer population, a patch may be released even for EOL versions. Clear criteria for exceptions prevent ad-hoc decision-making.

Publishing security advisories for EOL versions helps even without patches. Consumers aware of vulnerabilities can prioritize upgrades. Advisories should clearly state that no fix will be provided and recommend upgrading immediately.

What happens to documentation for EOL versions?

Documentation handling varies by team preference and infrastructure. Some teams archive EOL documentation separately, keeping it available but clearly marked as unsupported. Others remove EOL documentation entirely to reduce confusion.

Keeping documentation available benefits consumers who cannot upgrade immediately. Clear banners indicating EOL status and linking to current documentation prevent confusion. Archived documentation should be excluded from search to prevent new consumers from discovering outdated information.

Removing documentation simplifies maintenance and prevents accidental use. Redirect rules can send traffic to current documentation. This approach works well when the goal is strongly encouraging upgrades and EOL versions have minimal usage.

Summary

End of life policy defines when design system versions stop receiving support. Clear criteria, advance communication, and consistent application help consumers plan upgrades. Handling EOL transitions and documentation thoughtfully maintains consumer trust while enforcing necessary resource boundaries.