Migration guide: from skimage to skimage2#
Hint
This document is a work in progress and still subject to change.
scikit-image is preparing to release version 2.0 as a new package: skimage2.
Alongside skimage2, we will release version 1.0.0. Versions 1.x will be using the current API.
Versions 1.1.x will throw a FutureWarning upon import, as a means to notify users that
they should either upgrade to skimage2 or pin to version 1.0.x.
We have undertaken this to make some long-outstanding, backward-incomptible changes to the scikit-image API. Most changes were difficult or impossible to make using deprecations alone. To honor the Hinsen principle (that is, never change results silently unless to fix a bug), we introduce a new package, which gives users an explicit way of upgrading. Users also have the option to use the two versions side-by-side while they do so.
You can find a more detailed description of our motivation and discussion leading up to this in SKIP 4.
Updating existing code#
When switching to the new skimage2 namespace, some code will need to be updated to continue working the way it did before.
Note
For a while, you will be able to use skimage and skimage2 (the 2.0 API) side-by-side, to facilitate porting.
The new API may, for the same function call, return different results—e.g., because of a change in a keyword argument default value.
By importing functionality from skimage2, you explicitly opt in to the new behavior.
Deprecations prior to skimage2#
We have already introduced a number of changes and deprecations to our API. These are part of the API cleanup for skimage2 but are not breaking. You will simply notice these as the classical deprecation warnings that you are already used to. We list them here, because updating your code to the new API will make it easier to transition to skimage2.
To be defined.