Versioning

A version is a complete snapshot of your project at a point in time: the dataset, the impulse configuration, the trained models, and the project settings, stored together and kept indefinitely. Creating one does not change your project, and you can keep working immediately afterwards. Unlike a Git commit, a version includes your data as well as configuration, and restoring one replaces the project state instead of merging into it.

​

What a version captures

Each version is a full copy of the project, stored separately from the project itself. By default, the copy goes to storage that Edge Impulse hosts. Projects in an enterprise organization can store versions in one of the organization’s storage buckets instead, so the copies stay in your own cloud account. List versions returns the bucket and path of each version. Each stored version records:

• The version number and description you gave it.
• Who created it and when.
• The training accuracy, measured on the validation set, and the test accuracy, measured on the test set. Object detection projects record mean average precision at IoU 0.5 instead.
• Which impulse those metrics came from, if the project has more than one experiment.
• The total number of data samples.
• Whether the version is public or private.

A version only shows accuracy if you trained and tested the project before creating it. To record an up-to-date test accuracy, choose to run model testing when you create the version.

​

Creating a version

1. Open the Versions tab in the left-hand menu of your project.
2. Click Store your current project version.

   

3. Write a description. Record what changed and why, so you can tell versions apart later.

   

4. Decide whether to publish it. Checking Publish this version under the Apache 2.0 license makes the version public, which is covered below.
5. Click Save. Versioning runs as a job, so large datasets take a while to copy.

​

Restoring a version

Select a version from the list and click Revert to this version. Restoring overwrites the impulse and all project settings with the contents of the version. The underlying API only accepts a restore into a project with no data, so a restore returns the whole project to the version’s state. It can’t roll back a single change. Deleting a version removes it from the project’s list, but the underlying snapshot remains in cold storage.

​

Public versions

Publishing a version makes its data and state readable on a public URL, and lets anyone clone it into their own account as a starting point. Published versions appear in the public project repository. Because publishing exposes the dataset as well as the model, check what your samples contain before you publish: recorded audio, images of people, and file names carrying customer or site identifiers all travel with the version. A published version can be made private again, which removes the public URL.

​

When to create a version

Create a version at these points:

• Before anything destructive, such as rebalancing the dataset, deleting samples, or changing a DSP block’s parameters. These are the changes that are hard to undo by hand.
• At the point a model becomes a candidate for deployment, so that the exact data and configuration behind a deployed binary stays recoverable.
• Before handing the project to someone else, so there is a known-good state to return to.

Experiments compare several impulses on the same data inside one project. Versions snapshot the whole project, including the data. Use experiments to pick a configuration, and a version to save it.

​

Versioning in an organization

In enterprise projects, all collaborators see the same version history, so a version created by one engineer is a restore point for the whole team. Each version records who created it, when, and their description, so the version list also serves as a change log. Permissions work differently for people and API keys:

• Collaborators have full access to versions. A project collaborator can create, restore, and delete any version in that project. There is no setting that limits a person to reading versions.
• API keys can be limited. Version operations have their own scopes, so a key can read versions without being able to create or delete them. Use scoped keys for automation.

​

API reference

​

Additional resources

• Experiments for comparing impulses within a project
• Model testing for the accuracy figures stored with a version
• Project dashboard for project-wide settings and collaborators