Decky wants to "update" manually installed plugins wt higher version #

[Intoxicus]

Please confirm

• I have searched existing issues
• This issue is not a duplicate of an existing one
• I have checked the common issues section in the readme file
• I have attached logs to this bug report (failure to include logs will mean your issue may not be responded to).

Bug Report Description

If you manually install a plugin that's a higher verison number than what's on the sdecky store it notifies you to update to the lower version number plugin.

Expected Behaviour

It should detect a higher verisom number and set a flag to prevent update notifications.

SteamOS version

OS Preview

Selected Update Channel

Prerelease

Have you modified the read-only filesystem at any point?

No

Logs

Will provide if asked, seems unnecessary for this specific issue. Being that this is a minor? and very understandable, oversight log should not be needed.

[NGnius]

The current version comparison is pretty naive. It simply checks if the latest version on the store equals the latest version installed. If they aren't equal, then it's assumed there's an update available. This works fine for all regular use cases and the dev and advanced use cases usually involve people smart enough to know not to update to an older version.

Also parsing version numbers and trying to figure out which version is higher is a really hard problem to solve well (e.g. is 1.0.0 newer or older than 1.0.0a? 1.0.0alpha1?).

[Intoxicus]

I manually installed a preview version of TabMaster because it got broken by an update. But they want to wait until SteamOS pushes a specific change to stable.

TabMaster dev made a preview version for people with broken TabMaster.

That version is 2.3.1

The store version is 2.1.0

To make it not show the notification for an update I had to edit a json file so it thinks the manually installed version is 2.1.0.

I'm rusty when it comes to coding I'll admit. I didn't consider how the formatting does add some complexity to how to code it.

It may be a bit more complicated, but it's definitely a solved problem by many other devs.

Make the store the version number a variable that's an easier number to parse maybe?

Or have a specific prerelease flag so that it ignores the check for version numbers?

If you're just checking if the strings match then yeah, a greater than check requires some extra effort.

People have to have already come up with systems for this that you only need to adapt to your specific use case.

I respect you and am thankful for your work.

But it's a bit galling to be called "naive" when truly I haven't coded in years and forget such things that I should know and remember.

[NGnius]

But it's a bit galling to be called "naive" when truly I haven't coded in years and forget such things that I should know and remember.

I was referring to the code in Decky that does the version comparison, not you. Sorry if my wording wasn't clear.

I agree with you but I wanted to add some extra context because each solution that I can think of has some downside that someone isn't going to like. In order of (imo) best to worst solution:

• Use timestamps instead of versions to determine which version is newer. This doesn't work if different versions receive different updates out of order (e.g. a bugfix is applied to a stable version after an early access version is released).
• Have a (prerelease) flag to indicate this version might be newer than the one on the store. Either this disables update prompts until the user manually updates or it introduces an extra warning prompt before updating. This is by far the easiest to implement, though.
• Parse the versions and compare them to determine which version is newer. This enforces a specific versioning system onto every plugin dev.

[Intoxicus]

I apologize and thank you for the clarification.

[Intoxicus]

How about doing the prerelease flag.

But when they check for updates manually, it does an extra check. For everything with the "no_update" flag, it presents those updates only at that time. Also, with an option to clear the notification dots if they're not desired.

It's a fair bit of extra work, of course.

But it should help mitigate the potential for missing new stable updates for the most part.

[hubertsng]

I'd love an option in decky loader to just "ignore updates" or "ignore current update". Ignoring updates completely would stop being bugged for updates cleanly for sideloaded or downgraded plugins while ignoring the current update would stop being bugged for this example until a new update is pushed on the store.

[AAGaming00]

We have notification settings, pretty sure those support it

[hubertsng]

We have notification settings, pretty sure those support it

As I see, it's a global toggle. I'm talking about a per plugin option to disable checking for updates. Some pc hardware app I forget does something like this where when there's an update from autocheck, you can choose "update", "ignore this update", "cancel/ignore".

[hubertsng]

This appears to be solved in the latest release 2.11.1, haven't checked it on my device yet but it seems to be a per plugin option to disable update checks. Should be located in the developer section but should be able to be used for the end user for this purpose.

edit: Alright just checked it on my Steam Deck by downloading an older plugin. You have to enable developer mode on 2.11.1 but it's not in the developer or testing menu, its option to ignore updates is in the flyout in the plugins menu. Once you hit that, you seem to no longer be notified of any updates and the mass update button in the plugin menu ignores the plugin when updating. For my one downgraded plugin, it removed the button altogether since there are no plugins that can be updated.

[Gwindalmir]

* Parse the versions and compare them to determine which version is newer. This enforces a specific versioning system onto every plugin dev.

IMO, that should be done. If all plugins (at least ones on the store) were forced to use semantic versioning, then a reasonable guess can be made in most situations for which version is older or newer.

[RodoMa92]

This is already fixed by #601, it just need testing before merging.