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.
Application update notification feature has been integrated in the latest Slicer Preview Release. It will be included in Slicer-5.2 stable release and the update notification will be visible to users when Slicer-5.4 stable release is published.
We discussed in the pull request how the application update mechanism could be further improved in the future. I include this here as a starting point for further discussions:
For an application update notification I think in other programs Iām alerted more upfront with a pop-up dialog on application start? I think like TortoiseGit will do that and some others.
It makes sense to not do that for extension updates but I think more in your face for an application update would be desired. This would be in addition to the button in the Welcome module. The Welcome module button on its own itās not large and in your face and could be easy to miss and we donāt want users to miss updating to the latest application version.
I wonder if some simple widgets for application update notification or extension update notification would make sense in the QStatusBar area as some permanent widgets so it is present regardless of current selected module. The status bar area seems to be frequently used by other applications for notifications.
A statusbar area or āHelp->Check For Updatesā menu action is a place I would look first when Iām looking to manually check for application updates when Iām not using automatic checks.
As mentioned in Stable update notification - #6 by jamesobutler, it would be nice to put Release Notes somewhere to view (these maybe on download.slicer.org as well?). This being important for users to see if they really care to update from say Slicer 5.0.3 to 5.0.4 or if has fixes for things they donāt use. This impacts whether users download the new update.
QStatusBar area as some permanent widgets so it is present regardless of current selected module. The status bar area seems to be frequently used by other applications for notifications.
Popups and other more āin-the-faceā notifications would imply that users need more convincing. We donāt know yet if this is needed or not. Even if current notification is not sufficient we have the option of A. make the notifications more prominent; or B. making the updates easier and/or more automatic. I would get back to this question when we gathered some more experience.
A statusbar area or āHelp->Check For Updatesā menu action is a place I would look first when Iām looking to manually check for application updates when Iām not using automatic checks.
I agree, this would be the standard place. If it just switches to the Welcome module and opens the Updates section then it might fit into Slicer-5.2. If we need a separate reusable update widget then itāll have to come later.
it would be nice to put Release Notes somewhere to view (these maybe on download.slicer.org as well?)
Fully agree, it would be nice to add release notes. The current download.slicer.org API does not provide release note information, so this will have to come later.
Note that currently the main motivation for application update is not the release content but the fact that extensions are only kept up-to-date for the latest stable release (not for any of the previous stable releases). We might reconsider this and keep supporting two stable releases, as it is done in most other serious software. That would allow users to delay their upgrade for one release cycle, while now we expect users to update immediately when we create a new stable release (because we immediately stop supporting the āoldā release). The supported second stable release can be always the one right before the latest stable, or - to give users more time for the upgrade - a designated long-term-support (LTS) release. This would require increased maintenance and support effort from both Slicer core developers and all extension developers.
Ok I was thinking we would make it more in your face as a notification and if people donāt like it then back it off, rather than the other way around as you have now (less in your face and will potentially require making more visible). I would guess we would receive more feedback do like/dislike for the in your face method being the first implementation.
Popups and other more āin-the-faceā notifications would imply that users need more convincing.
I wouldnāt think they need more convincing but more notification that there is an update. A button in the welcome module only can easily be overlooked.
When I installed Slicer for the first time with this new update notification the check for updates checkbox was in the PartiallyChecked state. What does it mean to be in the partially checked state?
