A design system that cannot evolve will eventually be replaced, because evolvability and versioning define how a system changes over time without breaking the products that depend on it.
Change is inevitable, unmanage changes is what causes fragmentation and loss of trust.
Design for change, not permanence
Every component and rule should be expected to evolve.
Component evolution
v2.0.0
Added size="xl" variant
Non-breaking
v1.8.0
Added loading state
Non-breaking
v1.5.0
Extended variant prop with new options
Non-breaking
v1.0.0
Initial implementationFoundation
Assume components will need new variants and behaviors.Treat initial implementations as final.Favor extension over replacement when possible.Introduce breaking changes for convenience.
A list of tools and services related to this argument.potentially outdated
v2.0.0
Major
Removed variant="ghost"Breaking change
v1.5.0
Minor
Added size="xl" option
New feature
v1.4.1
Patch
Fixed button focus stateBug fix
v1.4.0
Minor
Added loading state
New feature
Adopt semantic versioning for the design system.Ship breaking changes without a major version bump.Document changes clearly with release notes.Rely on informal communication for updates.
A list of tools and services related to this argument.potentially outdated
Deprecation is part of a healthy system lifecycle.
Deprecation timeline
mds-buttonvariant="ghost"
Deprecated
v1.8.0
Use variant="outline"mds-buttononMdsButtonClicked
Removed
v2.0.0
Use onMdsButtonClickmds-buttonanimate
Removed
v2.0.0Use CSS transitions instead
Mark deprecated components and APIs explicitly.Remove features without warning.Provide migration paths and timelines.Force immediate rewrites on consuming teams.
A list of tools and services related to this argument.potentially outdated
Keep foundations stable while iterating on higher layers.Change tokens and primitives frequently.Evaluate impact before introducing breaking changes.Optimize for short-term speed over long-term health.
A list of tools and services related to this argument.potentially outdated
Evolvability ensures the design system remains relevant and trusted.
Clear versioning and deprecation strategies allow teams to adopt improvements
without fear of unexpected breakage.
Related references and bibliographypotentially outdated
Articles & Posts
Andrew Martin — Component Versioning vs. Design System Versioning
Component versioning and design system versioning are two key strategies for managing updates in design systems. Both approaches help teams maintain consistency, reduce errors, and streamline collaboration between design and development. But they serve different purposes and come with unique advantages and challenges. https://www.uxpin.com/studio/blog/component-versioning-vs-design-system-versioning/
Brad Frost — Design system versioning: single library or individual components?
