Regression: semver-compatible updates marked with X

[djc]

Describe the bug

For Rust dependencies I'm now seeing that available semver-compatible updates yield an upgradable decoration when only semver-compatible updates are available. This was not the case previously, and is undesirable at least for me (not sure if this is some new configuration).

Screenshots

I want to see only green checkboxes here, even if my Cargo.lock file is committed.

Desktop (please complete the following information):

• OS: macOS
• Version: 0.7.8

[MOzanGul]

Hi @djc, this is because of the latest update regarding support of .lock files. You can disable that feature in the Extension settings.
Let us know if that works for you.

[djc]

It fills this immediate need but then causes problems with #51.

[serayuzgur]

Hi @djc ,
Does this solves you issue ? Please test the attachment for test build. If works we will publish with new version.
PR

vscode-extension.zip

[djc]

Do you have guidance on how to install an extension from .zip?

[MOzanGul]

Hi @djc ,
Firstly, unzip the folder.
Then you need to uninstall the extension if there is an installed version.
After that, you can install the .vsix file following the instructions on the screenshot below.

[djc]

Honestly not sure if I can reliably reproduce this issue even with the marketplace version of the extension.

[MOzanGul]

Hi @djc ,
What do you suggest on how we we will go forward? We would like to know if you have any improvement ideas.

[djc]

I feel like I've clearly indicated the experience that seems optimal for my use cases (basically the way the crates extension used to work), and I would like your team to own the work to ensure and test that your extension implements that behavior. That is:

• I would prefer not to see an X for crates that only have semver-compatible updates, only for crates that have semver-incompatible updates
• I would prefer not to see an alarm light for crates where the required version (in Cargo.toml) is vulnerable but the locked version (in Cargo.lock) is not vulnerable

To me, as such the current configuration of where I have to specifically have to opt in to considering the lockfile seems too low-level -- it doesn't operate at the conceptual level which I think is necessary.

[masterflitzer]

what do you mean by semver-compatible updates (major/minor/patch)? i mean 0.7.2 is more up to date than 0.7.1 so the X is expected or am i missing something?

[djc]

In Cargo, 0.7.2 is semver-compatible with 0.7.1 and 1.10.3 is semver-compatible with 1.7.1. With Cargo, cargo update will let me painlessly update all semver-compatible updates, while I have to do manual work for upgrading across semver-incompatible boundaries (like 0.7 -> 0.8 or 1.13 -> 2.0).

[masterflitzer]

thanks for the explanation, i've always used crates/dependi as indication for when to update, not matter how the boundary is, the current behavior is pretty useful when you don't regularly run cargo update, i'd definitely like it if both ways would be supported e.g. through configuration (idc which is the default behavior)