Abstract
My team would like the ability to publish versions of multiple libraries simultaneously. Adding version control on a project level instead of on a file level would make this possible.
This behavior would more closely mimic the kind repo versioning that our engineering counterparts are able to do with git tool like gitlab and GitHub.
Background
Our team builds and maintains a design system used by a very large number of designers who work across a variety of themes and extensions libraries. In order to support the various needs of our users we have various library files for tokens, core components, and component extension libraries.
Frequently, changes to our libraries involve needing to make changes more than one library; any one of which is being consumed by any number of teams at any given time. We use semantic versioning and make minor releases on a quarterly basis.
Problem
We need to publish libraries with dependencies (tokens libraries, core components, etc) in order to incorporate those changes into higher level libraries (extension libraries). When changes to lower level libraries are published, those changes are published to all users of that library (internal and external). Publishing these changes publicly breaks the continuity with our coded components within our semantic versioning process; meaning that our Figma components are out of parity with coded components for X amount of time.
Idea
Having the ability to manage version control on a project level would allow us to make changes to dependency libraries and then publish the full project upon a scheduled release timeline.
This idea would imply that changes made to any file within a project would be immediately available to other files within that project.