Stable update notification

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.

1 Like

^ 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.

That issue was created around the time of whether to alert users automatically if there are updates available for extensions (not auto-updating, but alerting users of new versions of extensions). Currently checks for extension updates is a manual triggered action. Add "Update Extension" option under Manage Extensions · Issue #5470 · Slicer/Slicer · GitHub

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 Updates for extension or releases?

Either, i would prefer it enabled, but when the message is displayed (i.e there is na update), offer to turn update check off.

That way it is up to the user about Not getting notified.

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.

last_update_check=2022-05-31 18:58:54.201097


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.


They can use the “Download” button to automatically download the installer, close the current instance, and run the installer.

Thanks @jamesobutler that behavior sounds pretty reasonable to me.

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.

This is fine if it is executed right after the first run.

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.

1 Like

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 :slight_smile:

I agree, everything I said is in context of Stable release.

+1 for the idea of putting something on the welcome screen. Not too subtle or it could be missed, but better not to have a dialog.

I agree that these are great ideas!

  • 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.


A pull request has just been submitted that implements this feature. Feedback is welcome (by commenting on the pull request).

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:

from @jamesobutler:

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 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.

from @lassoan:

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 as well?)

Fully agree, it would be nice to add release notes. The current 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.

from @pieper:

I agree we can refine the way it behaves after some more experience.

from @jamesobutler:

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.

1 Like

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?