Publishing and Updating

As mentioned before (installing exporters), there are two ways of obtaining exporter packages - locally by installing it yourself or pointing to a GitHub repository that contains the exporter package.

If you created a new exporter and want to share it with others, the best way is to publish it through GitHub as it gives you several advantages, most importantly the ability to distribute updates between users effortlessly. In this guide, you'll learn everything about publishing and versioning works.

If you've already gone through Creating the First Exporter tutorial series, you know how to publish the exporter. In this case, feel free to skip to publishing updates.

Publishing the Exporter Package

There are a few steps that need to happen before you publish a remote exporter. Fortunately, the process is rather easy and most of the steps only happen once. Updating is then as easy as pushing another commit to GitHub.

1. Creating a GitHub repository

Navigate to GitHub.com and create a new public repository. Name it however you like. If you don't know how to publish a public repository, GitHub provides a good guide here.

Private repositories are not yet supported but are planned down the road

2. Setting the exporter connection to GitHub

Next, the exporter package needs to know it will be published in that specific repository. Open the exporter you want to publish, navigate to the configuration tab, and copy/paste the link to the GitHub repository you created. Note that it needs to link to the root of the repository.

GitHub repository configured

Close the configuration window to save it.

3. Exporting the local package

Next, export the package. You export local package by right-clicking the exporter in the exporter manager window. Select the export destination and an exporter package (bundle) will be created for you. Note that you can use this bundle to distribute between users directly if you want to.

Exporter package ready to be used

Right-click the package and select "show contents", which will show you what the exporter is made of.

4. Upload the content of the bundle into GitHub

Finally, take the content of the bundle and upload/push it to the GitHub repository you've created in the step (1). Root repository needs to contain only one directory, Contents, exactly replicating the structure of the exporter package.

If you've done everything until this point, your result will look similar to this:

Public repository with exporter definition. Readme is optional but nice to have

5. Testing the exporter integration

The second you push the exporter, it is ready to be used by others. You can test the integration yourself by deleting the exporter you've created (be sure to export it locally to have the backup, just to be sure!), and then re-adding it by clicking add new exporter > download from GitHub.

Downloading exporter from GitHub can be done through manager context menu.

You'll see the exporter show up, this time, connected remotely. It works just as before, but with more options!

Publishing Updates

The extra options come from the ability to push updates and distribute them to users of your exporter. This is great for many reasons but primarily it allows you to add more features and keep the exporter up to date with any changes happening outside Supernova.

For example, if you manage iOS exporter and Apple releases support for new technology (let's say SwiftUI), then you can make this accessible to all users the second you publish the update.

How do the updates work?

In order for Supernova to apply the update, two things have to happen:

  • New commit has to be pushed to the GitHub repository into the master branch

  • Commit has to bump the version of the exporter package. If the version is the same or lower, Supernova ignores the update and always keeps the latest version for the user.

Commit often, and release often as well. The system of updates is the easiest it can be, and users will be happy to know you are constantly improving what they use.

Note that you can commit without releasing updates as well! Updates are strictly driven by the version contained in the exporter.json configuration file. If you don't bump it up, the update will not be distributed.

Every time Supernova is opened, it checks GitHub repositories that are linked. If there are some updates available, it will be highlighted inside the Studio and users can manually trigger the update.

New version was published and is ready to be downloaded by users

When updates are available, manager for the exporters is shown to the user, notifying about specific packages that have updates available.

User can then update them manually, or update everything by clicking the Update all button.

Manually checking for updates

Supernova checks for updates every time it starts, but only on startup. This means you have to restart Supernova in order to force the new update. But there is also an option to manually check for updates, which is useful when testing that the new update was distributed.

Check for updates to trigger the refresh from GitHub, and update to the newest to install it

Simply navigate to the exporter manager, and check for updates by right-clicking the exporter you are interested in. And that's it!

Because GitHub API caches the files heavily, it can take upwards of 3-5 minutes before the new version shows up. We suggest an easy workaround - make a coffee after you pushed the commit to the repository and it will be available then!

Congratulations!

Now you are a master of the exporters, you know how to publish them, create and update them and how they internally work. The next thing is to start tinkering with Blueprints and Blazar, the language that powers them.