While it doesn’t have a down side, it doesn’t work well Automated building and releasing Plugins on Github with Github Actions. The script there generates either plugin ids with the git hash (as pictured above) or I think it can create normal version numbers through tags but then you have to tag a version with the previous versions numbers.
I’ve mostly been using the git hash version when distributing to my testers. I’m sure I could remove the githash sufix from those builds. I guess I could move the hash into the name so that people can tell me which version they are on…
But surely there must be another work around I’m not thinking of?
If the version string starts with ‘2’, but is different in any way, it will cause a downgrade. VCV has no notion of “semantic versioning”. afaik there is no way around it. But of course you can look in the VCV code and see what the real situation is.
Version check is very simplistic as you stated. If the local plugin version and the one extracted from the online library manifest are different (just different, no higher/lower comparison is done), then a plugin update is marked as required. See library.cpp#L248 for the actual test.
I turned auto checking off in settings.json, so no red dot unless I hit the Library menu. Since I periodically test stuff I would otherwise have to ignore that dot forever. The version check could use a serious overhaul, but this makes it workable. So any real updates I apply manually one after the other, ignore the ones I have later versions of running and then quit and restart, no red badge in library menu. Works for me.