Motivation
Now that the newest major release at the time of writing (0.3.0.0) is live, it would be useful to relax the napari version pin to allow users to install the most up-to-date napari version, and keep development closer to napari releases.
TODO (API breakage)
Timing
This should not be merged immediately, in my opinion. Confirming that the current refactored version works well on napari==0.6.6 should come first, and once we feel confident the plugin is in a proper stable state, we should consider making a minor release with only the version bmp (and not as part of shipping broader fixes/refactors) to avoid compounding effects.
Viability
A few notes on expected behavior and safety:
- DLC GUI auto-update will pull the latest napari version (as it always uses
--upgrade)
- The newly added compat layer should help mitigate breaking API changes
- The debug log utility system should help track which version people use
Alternatives
Overall, since the plugin makes fairly deep use of the napari API, especially around Qt events, Points layers controls UI, and layer wiring, a preferable alternative may be to periodically check the newest napari version, validate first, and then bump the version.
A middle ground would also be to set an upper bound on the major release, e.g. since 0.7.0 seems compatible with or v0.3.0.0, we could pin to >0.6.6,<0.8 to retain fixes but avoid potential breaking changes, such as _qt_window access deprecation.
Motivation
Now that the newest major release at the time of writing (0.3.0.0) is live, it would be useful to relax the napari version pin to allow users to install the most up-to-date napari version, and keep development closer to napari releases.
TODO (API breakage)
Timing
This should not be merged immediately, in my opinion. Confirming that the current refactored version works well on napari==0.6.6 should come first, and once we feel confident the plugin is in a proper stable state, we should consider making a minor release with only the version bmp (and not as part of shipping broader fixes/refactors) to avoid compounding effects.
Viability
A few notes on expected behavior and safety:
--upgrade)Alternatives
Overall, since the plugin makes fairly deep use of the napari API, especially around Qt events, Points layers controls UI, and layer wiring, a preferable alternative may be to periodically check the newest napari version, validate first, and then bump the version.
A middle ground would also be to set an upper bound on the major release, e.g. since 0.7.0 seems compatible with or v0.3.0.0, we could pin to >0.6.6,<0.8 to retain fixes but avoid potential breaking changes, such as _qt_window access deprecation.