Is connected mode used: Connected to SonarQube 9.9 LTA
About once per day, the SonarLint plugin shows a popup on start informing me about the new version 10.10 of the plugin (even though there aren’t even release notes for that version available yet on the homepage, but that’s besides the point).
There does not seem to be any dedicated config option in the SonarLint settings to disable these notifications/automated update checks, and SonarLint also does not seem to honor the IDE setting that disables automatic software updates in general.
We have a rule in our company that developers are not supposed to automatically update the Eclipse distribution and the embedded plugins due to risk of things breaking (we already had numerous times in the past where an update broke plugin functionality because not all plugins are equally well maintained, so each update to the distribution is a more elaborate process that takes several days to put together and test compatibility. Updating just individual plugins is also not an option, because they can cause updates of transitive dependencies used by other plugins which can still end up breaking them).
Therefore it would be good if the plugin would not annoy developers with a prompt they cannot follow up on.
I also tried a workaround of manually setting hideSonarLintVersionHintDate=31.12.2100 in the org.sonarlint.eclipse.ui.prefs file, but this does not seem to make any difference and just gets reset to the current date on next IDE start.
Yes indeed, there is currently no option to disable this check. There is currently only an internal system property (sonarlint.internal.hideVersionHint) for us to disable it in tests. You could use it for now as the preference files you edited to save the current date, not the date until the user is asked again.
There is also no option on the notification to don’t show it again as we intended users to get more users to update quicker to newer versions instead of sticking with old ones that are not supported.
I do see, however, that in cases like yours, it does not make sense to ask on a daily basis. I’ve created a ticket for that HERE to add a new Remind me later option so that the notification does not show up daily but rather every week or every two weeks (I’m not sure about that yet). Maybe even only show the notification the next time an even newer version is released.
We don’t want the users to be able to completely miss out on available updates.
Regarding the point about release notes, once the release is done, they are firstly available on our GitHub Release page, and it takes some time to get them out on the Community Forum. This is due to the fact that the GitHub release happens automatically while the announcement here is done manually.
Thanks for that internal property. I’ll stick to it for the time being.
As for “remind later”, it could still get annoying if it occurs regularly, since it would just never be relevant for us. We update our IDE configuration at most twice a year, so we’d be pretty much constantly outdated. But assuming that the workaround via the system property keeps working, I’d also be fine with just sticking to that for our special needs.
I do wonder why SonarLint needs a separate update reminder in the first place, given that Eclipse already has its own update and notification mechanism available:
I get that you may want the extra reach and a link to the release notes, but it feels a bit intrusive if you configure your IDE to handle updates in a certain way and then have a plugin completely disregard these settings and do its own thing anyways.
to clarify why we don’t rely on the configuration that is done for Eclipse itself:
Honestly, at that point, I also looked at this but was a bit skeptical due to the fact that users can disable this as a whole and due to the fact that users can install the plug-in in many different ways except the marketplace or using the Eclipse Update Site directly (local mirror, specific version installed, installation from disk or archive, … that would not be showing whether there is a newer version available as well).
That was what drove me away - I have the automatic check disabled for what feels like forever.
In the latter cases when the plug-in is installed in a way that Eclipse won’t find updates while checking for newer versions, we would need to trigger our own “update check” alongside or after the automatic check from Eclipse itself.
At that point, I did not find an easy way to hook into the Eclipse automatic update mechanism and check when the user had automatic updates disabled or the installation was one where no updates could be found.
Both of these might be worth investigating in the future, but first, we will implement the ticket to notify the user less often and see whether users will still be bothered by this.
On the point about the IDE’s configuration vs. plug-ins checking on their own and this being intrusive: I agree with the point only to a certain but limited degree, as there is no contract between the IDE and the plug-ins themselves regarding what configuration is also valid to the other.
In our case, it was implemented to raise awareness and to convert more users to more recent versions, which would be beneficial to both users for bugs fixed or improvements or new features as well as us as developers for faster feedback (our plug-in is free, for a paid one, this might be a different practice).
Of course, as you mention, this happening too often might lead to annoyance. This happening the right amount of times will be a good tradeoff for users not limited to updating only a certain number of times a year - even though I also see that way for enterprises to make more sense.
just for letting you know. With SonarQube for Eclipse 10.12 just released we changed the prompt to only appear every two weeks.
Once you update your IDE configuration again (with the then latest version of SonarQube for Eclipse) give it a look and whether it is still annoying.
I would also be interest in what is the exact reason for only updating the IDE every 6 months? Not trying to convince you to change it but it would help us understand our (power) users better and their needs.
Thanks, two weeks definitely sounds better, although I’d still try to stick to the system property for our use case if it’s still supported. I simply prefer in this case to not harass our developers with prompts that are non-actionable (at least in our specific use case).
The primary reason for not updating frequently is the time it takes to prepare the update and verify its stability. Similar to how companies stick to LTS releases of software instead of following the bleeding edge.
I basically start with a vanilla distribution every time instead of using the built-in update mechanism and then install our corresponding plugins (and sometimes also evaluating new plugins). We also use tooling that synchronizes the local workspace preferences with defaults from a central server, so when there is a new Eclipse distribution, I need to check whether any relevant preferences have changed and need to be added to the central default - which also means that different internal Eclipse distributions are not backwards-compatible between each other. Each new release is basically a breaking change for us, and it’s also tailored to a specific version of our software, so that developers may be required to use a specific internal Eclipse distribution depending on which milestone of the software they are working on.
Not all plugins are immediately available in a compatible version when a new Eclipse release hits; some may take a few additional weeks to follow suit.
Eclipse also occasionally changes its API in non-backwards-compatible ways, which can cause older plugin versions without available updates to stop working or even break other things in the IDE if we just update some of the stuff to the new version. We’ve already had that happen a few times in the past.
And some of the plugins we are using are not properly maintained anymore and were forked by us to make them compatible with current Eclipse versions. We also forked some other plugins to add customizations that are specific to our build environment in order to solve performance issues; which means in order to upgrade to a new Eclipse release, we need to update our forks as well, thus increasing the cost of upgrades for us.
A case could also be made about offering less attack surface for software supply chain attacks by not updating plugins via the built-in function but instead only when doing controlled tests for the new internal distributions.