Skip to main content

Upgrade VIKTOR version

To upgrade the version of the VIKTOR SDK used in your app, modify your requirements.txt with the desired version:

viktor==14.8.0

The latest SDK version and a list of all notable changes can be found in the changelog.

Don't forget to (re)install your app after modifying the VIKTOR version (or any of the other app dependencies), using:

viktor-cli install
note

When creating an empty app using the CLI, the latest VIKTOR version (at that time) is automatically set in requirements.txt.

Versioning

VIKTOR uses semantic versioning to denote different versions of the SDK. The convention that is used for the version number has format vX.Y.Z, where:

  • X is the major: increments when a backwards incompatible change is introduced.
  • Y is the minor: increments when a new functionality is added, without breaking compatibility with older versions.
  • Z is the patch: increments when the code can drop-in replace the previous code, or when documentation is added/changed.

Release cycle

Currently, we expect to release a major version of the SDK once a year. Support for the previous major version of the SDK will be dropped 15 months after the release of a new version. Minor versions of the SDK are released more frequently and can be expected to be released every month. Patches might be released in between minor versions containing bug fixes or changes to the docstring.

Release schedule Release schedule

The workspaces with app versions that use an unsupported version of the SDK cannot be accessed anymore after the support period ends. We will notify developers of upcoming end-of-life dates well in advance so there is enough time to upgrade apps to a newer version of the SDK.

Upgrades & deprecations

Patch (v1.2.3 -> v1.2.4)

Patch versions of the SDK are backwards compatible and, therefore, these releases can be used without modifying the code of your application.

Minor (v1.2.3 -> v1.3.0)

Minor versions of the SDK are backwards compatible and, therefore, these releases can be used without modifying the code of your application.

Minor versions include deprecation warnings, that inform the developer on upcoming breaking changes that need to be addressed in order to use the next major release. Deprecation warnings are logged by the CLI if the code of your application requires modification. It is not mandatory to fix deprecation warnings when updating to a minor version. To make addressing deprecations easier we have started shipping automated code fixes. These automated fixes can be applied using the CLI fix command.

Major (v1.2.3 -> v2.0.0)

Migration guide v13->v14

A guide on how to migrate your app from v13 to v14 is available here.

A new major release introduces backwards incompatible changes. This means that the code of your application should be updated in order to use the new major version of the SDK. To make this process as easy as possible we provide you with upgrade instructions for each change. To speed up the process of updating your app we have started shipping automated code fixes. These automated fixes can be applied using the CLI fix command.

note

From experience, upgrading your application to the next major version can be done in the order of a day development time. If you are having difficulty updating your application to new version of the SDK please do not hesitate to contact us.