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.16.2
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 Python dependencies), using:
viktor-cli install
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
Workspaces with an app version that uses an unsupported version of the SDK can still be accessed after the support period ends. However, archived workspaces cannot be unarchived in this case. 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
)
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.
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.