Hey @spiff, thanks for reaching out!

Right now, the best workaround would be managing the libraries separately, as 2 different libraries Old and New. Be advised that managing the design system this way may become frustrating unless you’re diligent in keeping all assets’ naming convention consistent across all versions.

Here’s an existing topic from the community that may help you think this through: Two separate libraries?

You could consider separating “future work” from “this is a mirror of production.” Our team tries to do this using branches for “future work” and then when that work ships, it merges to the main branch (which should be a perfect reflection of what’s on the production site). This gives designers a space to work on new stuff, but without compromising a reference that you’re not ready to have receive updates.

An issue with this is it could lead to branches being open for a long time. This largely depends on how you scope your work, but having branches hang out and accumulate many big changes could lead to issues when you go to merge. When you merge, the memory usage will spike as Figma reconciles the differences between the branches. Other folks have experienced crashes when trying to merge too many big changes at once.

All of this assumes you’re on a Figma plan that has branching! You could potentially do the same thing (with more work) with a workflow that goes something like this:

1. create a “production mirror” file


2. when feature work comes up, peel off a copy of the production mirror file to execute your changes


3. when those changes go live, replace the production mirror content with what was in your file.

^ but that can get messy if you have many people doing step 2 concurrently.

Thanks @dvaliao. We run a continuous delivery process, so there are multiple ongoing projects and the updates aren’t so clearly delineated. I guess I could consider each project to be a single version increase, but that still means there’s a new/duplicated library for each new project. I suppose that’s workable, though I suspect I’ll end up with a lot of library files. I think I’ll also have merge issues if multiple projects are being iterated at once.

That said there’s something here that I’ll think more about, and I’ll read the link you shared to see what’s been covered already. It seems like there’s a viable solution here and it may be better than having multiple variants of each component. Thanks for the suggestion!

I had no idea Figma supported branching! I have some reading to do. Thanks for the suggestion.

Yes! If you’re on the Organization plan or higher then you have access to the branch feature:

An unexpected benefit to using branches is that branches can help keep file memory in check.

Coming back to this thread again, I realized you may also be interested in @Nathan_Curtis’ writing on versioning component libraries.