Skip to content

Versions

Learn how to manage application versions (create, get, update, delete) with your tool of choice.

  • CLI: the Nextmv Command Line Interface (CLI).
  • Python SDK: a Software Development Kit (SDK) for Python developers.
  • Cloud API: an HTTP API for developers to integrate with the Nextmv platform.

An app version represents a specific executable code. You can think of a version like a Git commit tag. It is a snapshot of the code at a specific point in time.

  • In the case of an interpreted language like Python, the version is the set of files that make up the app.
  • In the case of a compiled language like Go, the version is an executable binary.

Once a version is created, the executable code will always be attached to this version no matter how many other ones are published. This is, the code is versioned. You can update the name and description of a version, but you cannot change the referenced executable.

  • Creating versions is only available for custom apps.
  • With subscription apps you do not manage the available versions, though you have access to all published versions for the Marketplace app you’re subscribed to.

To create a version, you first need to deploy the application. Once the executable has been pushed to Nextmv Cloud, you can version it. The latest pushed executable is always the one that is available for versioning. You can create as many versions from an executable as you want. Once you re-push the application, the latest executable will be overwritten.

Tip

To prevent losing your work, we recommend creating a version immediately after pushing your application. This way, you will always have a versioned copy of your code.

Versions that are published to a subscription app are of the form v<Major>.<Minor>.<Patch>. When associating an instance to a version, you can use either:

  • The complete version, i.e.: v1.0.2.
  • The major version, i.e.: v1. In this case, the instance will always be assigned the most recently published complete version that matches the given major version.

For example, if an instance uses version v1, and the most recently published executable code is changing from version v1.0.2 to v.1.1.0, new runs will start using the code associated to v1.1.0. You can think of this behavior as an auto-update, and it is the default behavior for subscription apps.