How to implement staged releases for large design systems

Help us improve Penpot Feature requests
1

Context
We’re a design system team working with one large shared library that’s used by all designers across the organization. This library contains complex nested components — for example, a Badge component that’s also used inside a Button component. The Button itself is a single component with multiple variants: it can act as a button or an icon button, and we have 5 different types/variants layered on top of that plus all the states (MEGA haha).

The problem
Because library changes are applied instantly to every file that uses the library, we have no way to stage, review, or release updates in a controlled way. Every edit we make propagates immediately to all consuming files. This causes two big issues for us:

  1. No safe way to iterate. We can’t work on a change, test it, and then “publish” it when ready — it’s live the moment we touch it.
  2. Performance/stability problems. With deeply nested components (Badge → Button → variants), instant propagation across many files causes our files to freeze or crash regularly.

What we’d like
Some kind of versioned/staged release mechanism for libraries — e.g. a way to work on library changes in a draft/branch state, and only push updates to consuming files when we explicitly publish a new version. This is standard in most design tools (Figma’s library publishing model, for example) and would make it possible to maintain a large design system without constant instability.

Has anyone found a workaround for this, or is there a roadmap item for library versioning/release control? Happy to share more details about our file structure if that helps diagnose the freezing issue too

4 Likes
2

The only workaround we’ve used up to now has been to duplicate the current version of our library and work on changes in that new copy until it’s ready - sending an alert out to all team members when the new version is available and to please use it going forward in new files (We’ve also got a process to detach a library when visuals are complete on a feature so that it’s ‘locked in time’ and won’t run the risk of trying to bring in later updates to a library if its viewed following completion).

We’re a relatively small team though with a young design system, so for the moment something like this works, just. However a more controlled, predictable way of releasing versions will be hugely useful as both our team and the system grow.

1 Like