I brought his up earlier on the forum. For stable releases, we need to have a mechanism that will check whether a newer stable version is available and if so, notify the people (with an option to disable that check).
I suspect there are a lot of people who are using the older stable (4.11) and are not aware that a new stable is released, unless they are actively tracking the Slicer community. Or likewise there will be a new patch release of the stable (as I understood) soon, and people who are using 5.0.2 (current version), will not be notified of this.
^ Itās an issue being tracked and currently in the Slicer 5.1 milestone. Itās not going to be something for this Slicer 5.0.x release, but maybe for a future feature release. Slicer 5.0.x announcements will have to come from the community announcement which is one of the last steps to the release process which hasnāt been completed yet.
Does anyone want to chine in on whether checking for updates should be on by default or only if a user opts in? Maybe thereās should be a dialog box the first time you run slicer on a new machine asking for preference? (extra dialogs at start are annoying too of course).
Checking for extension updates currently happens when you go to the extension manager, which is itself a network operation, so no user approval is really required. Checking for updates of the application at startup would allow us to track how many times the software is used, which would be useful for us, but some people might consider it a privacy issue (although Iām sure other software does it all the time and people donāt seem to care much anymore). I was wondering if anyone feels strongly one way or the other how we approach this.
Based on this comment, it would need to be opt-in.
Iāll provide information below about my current implementation to serve as ideas for Slicer.
I currently have support for auto version checking for my Slicer custom app by checking a release notes file on the web and comparing the latest version with version of my custom app being run. The update selection is saved as a user setting (False/True or missing if deferred decision by pressing āCancelā). They can manually check with an action in the menu bar at Help->Check For Updates.
If the user has selected āManualā, Iām a little bit annoying and I will display a message on the status bar if they havenāt manually checked for a new version in the past 30 days. See code below.
long_number_days_since_last_check = 30
if time_since_last_check > timedelta(days=long_number_days_since_last_check):
message = f"It has been over {long_number_days_since_last_check} days since the last check for a version update. Please go to Help->Check For Updates."
slicer.util.mainWindow().statusBar().showMessage(message, 30000) # shown for 30 seconds before cleared
If there is a update available I show release notes for all versions between the current version and the latest version available.
I allow the user to āIgnoreā the version update (saved as a user setting) if they donāt care about the update (often minor bug fix releases) and if they have āautomaticā check mode turned on, then they will only be alerted of the next available release.
[Application]
ignore_version=1.13.1
They can use the āDownloadā button to automatically download the installer, close the current instance, and run the installer.
I think there is a huge difference in terms privacy between going to a website and comparing a revision number and reporting to user that there is an update, vs doing telemetry on their usage habits.
A silent change (that is opt-in behavior) like this will defeat its primary purpose, which is to bring unengaged users more up-to-date with Slicer. First they have to know thatās an option.
The pop-up I described that asks the user to opt-in does not seem to be a silent option and seems to be a very respectful option with clear transparency.
Yes, or maybe after a few runs, with a message like āYouāve used Slicer 10 times now and we hope you are enjoying it. If you want to have Slicer automatically check for updates, click Ok.ā. This way it wouldnāt be in your face the first time you start the app (we already have the ānot for clinical useā dialog).
Another option could be to check the date, and if the version is more than 6 months old offer to check for updates and/or turn on auto update check.
If we are going to be this verbose, I suggest making it clear in the message why staying up-to-date is important. May be something like āExtensions can only be updated for the latest stable release.ā
I would discourage any update notifications for Slicer Preview builds. We canāt be certain that the latest preview build is a better working option than the current Slicer Preview that a user may be using as there are periods of instability as various dependencies get updated. Then there would be no need for a statement like āExtensions can only be updated for the latest stable releaseā because there would not be any update notifications for Preview builds.
Good topic, maybe we could put an update message on the welcome screen only if new stable builds are available:
Update notification dialog boxes are quite aggressive and may be disabled soon ? The click should download the new version, ideally with all previously loaded and matching extensions, and restart Slicer
offer enabling auto-update in the welcome dialog and whenever doing manual update
slightly nudge the users to enable auto-update by displaying a ācheck for updatesā button in Welcome module or in the status bar after every month or so
show what has changed since the running Slicer version and the latest Slicer version
allow the user to ignore specific application releases
explain why it is important to update (Slicer is constantly improved)
explain why statistics are computed from application and extension download count and location (demonstrating impact helps us getting grant funding; knowing which extensions are used helps us prioritizing developments)
Iām working on implementing robust and quick auto-update check and auto-install is updates for extensions. Itāll be ready in a few days. Auto-update of application version could be done at the same time as extension auto-update and could be controlled by the same opt-in for switch.