When I make changes to a component and I’m ready to publish, there are 2 options;
I made a few tweaks and wanted to test out the component only within the team project so I published it within {Project name}, however, viewers of the {Project name} are still able to see the changes. I believe this is a bug and shouldn’t happen.
What’s wrong with this?
This publish should be sandboxed within the design system team and not org-wide. Then what’s the point of having this feature if both options are giving the same results?
What I’m trying to do is, to test my component within the design system team before its released widely to the whole group. So I save a version history on my library, and then I make the changes to the component > I release it within the Project name so that I can test it within the internal team. If we approve all good I can publish it within the org, but if not I can revert back to the version history.
If a tweaked component is found and used by the org within that internal review phase then its a big issue.
Hi everyone!
We are encountering the same issue in our organization. I have set up two libraries: Foundation and Components. There are times when I need to make additions or modifications in the Foundation library and then publish these changes to be able to access them in the Component library. However, I want to make these changes visible only to myself or my design system team and not to anyone else. Unfortunately, I’m unable to do that using the “Publish to everyone in team” or “Publish to everyone in organization” features.
These options don’t seem to work for us at all. The only potential solution that comes to mind is to create duplicate copies of these two libraries and rename them as “LibName_Stage environment.” This will ensure that these files are only accessible to our team and will serve as a space where we can carry out releases and test our ideas and components without making them visible to the rest of the organization. However, this approach means that when everything is tested and confirmed to be good, I’ll need to replicate these changes in the production libraries, which could lead to potential issues if something is missed during the transfer.
Do you have any suggestions on how to test and iterate changes between libraries without making the rest of the organization aware of these changes? Perhaps something like internal releases or a similar concept?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.