Publishing packages and version control
Note
You're currently viewing a topic describing a Studio feature that's in limited availability. For more information, see: Studio (new experience).
For all other Studio features, see: Studio.
Studio gives you the ability to publish and control the version of packages and assets available to users through apps. This version control allow you to thoroughly test new features and configurations before using them productively.
To publish your package:
Click the version control button and then click Publish:
Add a version number, summary of changes, and select the package assets you want to publish.
For our recommended version number formatting, see: Package version control.
Click Publish.
Your package is published, with the live version available within Apps to those who hold the necessary permissions. For more information, see: Apps.
Package version status
When creating, editing, or viewing package versions, the following status are available:
Draft: This package is currently being edited and the changes made are not yet visible to app users. Packages are considered as draft before they are first published and also when subsequently creating a new version of a published package.
Published: This is the version of the package that is currently visible to users. When a package is published a version number is assigned (see: Package version control) and previous changes to that package can be tracked.
When a package is published, only the views and analyses are visible to app users. Neither the knowledge model nor any created skills are shared.
Archived: This is a package that was previously published but has since been archived (with packages being automatically archived once a new version is published). Archived packages can still be viewed by users with package editing permissions and all archived packages can be edited and restored when necessary.
Package version control
For the version number format, we recommend using: MAJOR.MINOR.PATCH (e.g 1.0.0)
Major: A complete update or shift in the current view. This can include changing different components, moving a handful of components around, or adding and removing visuals from the view. These changes would greatly affect your app users if no communication was given in advance.
Minor: Tweaks in the apps that won’t necessarily require communication or messaging to your app users. Examples include editing a KPI, making color changes, or changing chart types.
Patch: Very small changes that may go unnoticed to your app users. Examples include an update to the calculation of a KPI or changes in titles.