Setting to stop constant upgrade message

[jonahbeckford]

With the DkML distribution (ie. the Windows one) the premise is to have a set of well-tested packages available to an end-user. "Well-tested" means a couple hundred of the most important OCaml packages are pinned to what is known to work on Windows. In fact, there is an offline version of the DkML installer that takes this idea further.

But having a stable set of versions, or an offline installation, is not supported:

There is a newer version of ocaml-lsp-server available. Consider upgrading from 1.15.1-4.14 to 1.16.2. Hint: $ opam install ocaml-lsp-server=1.16.2 and restart the lsp server

Every time VS Code launches that message is shown.

Can that message be shown once? Or have a "Stop this from being shown" action? Or have some hook (environment variable?) to stop the messages entirely?

Thanks.

[mnxn]

I've noticed this annoyance too.

However, while it would be possible to suppress this warning, my concern is what happens when extension depends on newer features in ocamllsp. This could lead to a confusing situation in which an extension feature is not working and a user has already suppressed the warning that explains the version incompatibility.

As far as I know, most other VS Code language extensions depend on the newest version of their respective language servers.

Have you considered bundling older .vsix extension packages from the releases in your offline installer? That way, you can "pin" the extension version in a similar way to the opam packages.

It is also possible to install older versions of the extension directly in VS Code:

After that, VS Code should ignore updates to the newer incompatible versions of the extension by default:

[jonahbeckford]

Okay, if incompatibility is the problem that is being solved, that is useful to know.

Several issues with constant upgrade messages as the solution though:

1. I haven't seen other plugins have unavoidable, repetitive upgrade messages. Actually, from my own experience I can't find a single one (and I'm a heavy vscode user ... TypeScript, C/C++, Java, OCaml, Python).
2. This affects a growing percentage of the user base. Asking them to do a custom install is a bad user experience (and makes it seems like the users are second-class).
3. This custom install would be a fork, no? And that fork would still presumably have to disable the offending UX message? So, the code would still need to be updated, but now that change would be in a fork (with forever maintenance costs).
4. Most important: The constant upgrade message does not stop the incompatibility problem. And the upgrade message doesn't even tell the user the consequences. And the appearance of the upgrade message is not correlated to the appearance of the incompatibility problem: when and if OCaml breaks, the user won't know why it was broken.

By contrast, other vscode plugins may do a warning but provide you a config option to disable/fix the warning in the message itself. Examples:

• lldb.suppressUpdateNotifications. The extension activation code and button are at https://github.com/vadimcn/codelldb/blob/f4b6ad6dfc20a31da922146b78cbea9543997e5d/extension/main.ts#L102-L116
• C_Cpp.configurationWarnings. The toggling is at https://github.com/microsoft/vscode-cpptools/blob/44e2a0ec4c11f9d313b7bee0f95371601c30cc68/Extension/src/LanguageServer/client.ts#L2119-L2136

Or they add a problem in the "Problems" pane, or auto-open the "Output" pane with a "This needs {tool} {version} or higher" message ... but only when the incompatibility is detected.

Or the more advanced ones provide their own compatible binary during the extension activation. (If you need a GitHub/GitLab CI job that always builds the latest ocamllsp.exe on Windows, that could be embedded / auto-downloaded ... that could be provided). That assumes that the latest ocamllsp.exe is 100% backwards compatible with old versions of Dune (is it?).

[mnxn]

Sorry for the late response. You make some good points and I agree that something needs to change.

First, to address a few specific things:

• This custom install would be a fork, no? And that fork would still presumably have to disable the offending UX message?

  No, a fork wouldn't be neccessary. The most up-to-date version is statically embedded in the extension. That means installing version 1.12.1 of the extension (either through the marketplace or .vsix file) will not raise warnings when used with the now out-of-date version 1.15.0 of the language server. If an older version of the language server has to be used, an older version of the extension will be less likely to have incompatibilities.

• the more advanced ones provide their own compatible binary during the extension activation.

  This would be the ideal solution, but would require many different binaries for the combinations of user systems and OCaml versions. At one point the extension had support for automatically building and installing tools into a hidden switch, but work stalled after UX issues if I remember correctly.

Now, here is my proposed solution to this issue:

• Add a Don't show again button to the upgrade message that sets the value of a new extension setting.
• Edit the wording of the upgrade message to mention the possible incompatibility from using an older version.
• Change the color/icon of the status bar item when the language server is out of date. The status bar item is currently only used for changing sandboxes, but it could be extended with more extension information. This is less intrusive than an upgrade notification without completely hiding the information. I believe there are some language extensions that do this already.

[jonahbeckford]

Your proposed solution sounds really good.

[rgrinberg]

Yeah, that sounds reasonable to me as well.