How to deal with version mismatches and incorrectly reported versions

[VladK]

I am a big fan of KVR Studio Manager, and hope its development will continue.

Aside of inability to export plugin lists, the main challenge I see is incorrect plugin versions in the main KVR DB, in most cases these are either caused by different versions of the same plugin for different OSes, or by version mismatch between a plugin suite and individual plugins inside.

I see few enhancements and workarounds that can be implemented in KSM:
- allow for manual version override of the installed plugin/library version in the KSM client;
- force developers to separately report versions for standalone application, for each supported plugin format, and do this by each OS supported;
- force developers to separately report versions of each individual item in a suite;
- implement a user reporting form in Studio Manager to be reviewed by KVR stuff with fixes applied in the main KVR database.

I would also love if the My KVR web interface more closely mirrored the data from KSM.

Below are few of many examples of mismatches I see for my plugins in KSM:

1. Mercury Piano, by Wavesfactory: KVR DB shows version 1.0 for AnyOS, and "Not Yet Released" for Win and Mac. As a result, my copy is placed in the "Unsupported" tab.
Same for Pearl Concert Grand, by Impact Soundworks. I guess the logic for handling of AnyOS is broken.

2. Some VSL plugins, such as VI Pro and Vienna Imperial still show outdated (and incorrect) eLicenser versions after VSL switched to iLok, and as a result, are incorrectly placed in "KVR Newer" tab.

3. ARIA Engine / Player, by Plogue: ARIA Engine is developed by Plogue and is not a plugin, while ARIA Player VST plugin was developed by Garritan. They have different latest versions - last version of ARIA Player VST plugin is 1.9.5.9, while the latest engine version by sforzando is 1.9.8.1. Garritan installation file is marked as 1.9.6.9 because it includes the engine 1.9.6.9, but the plugin version there is still 1.9.5.9. As a result, KVR shows the version 1.9.6.9 as latest for VST plugin which is incorrect. It must be 1.9.5.9.

4. SPARTA suite shows version 1.8.1 as latest in KVR database, but this is the version of the suite. This suite included multiple plugins with prefixes sparta_, compass_, cropac_, hades_, hodirac_, hosirr_, with each plugin having its own version (and all these versions are below 1.8.1). As a result of incorrect logic, KSM places all plugins from this suite with prefix sparta_ to "KVR Newer" tab, and all other plugins from the suite - to "Not Found". KVR DB should have a separate entry for each plugin in a suite IMHO. This can be implemented, for example, as nested key-value array of plugin data inside the main suite entry.

5. Some developers deliver plugin as a single zip file with installation files for all supported OSes placed inside, but inside the zip, versions of plugins may differ by OS. From my experience, this usually happened when developers implement the compatibility update for the Mac version without updating the Windows version, Pumper 3 by W.A.Production is a good example. The KVR DB shows the version 3.2.0 of the repackaged zip file as latest version for both Mac and Windows while the actual Windows version in zip file is still 3.1.0, and as a result the installed Windows version falls in the "KVR Newer" tab which is incorrect.

6. Version of standalone application may differ from VST3 plugin version. Example: SynthMaster 3 by KV331 Audio: standalone is 3.4.6, and VST3 is 3.0.0.16731. Same issue for SynthMaster One: standalone version is 1.6.2 and differs from VST3 (1.6.0.16270).

[VladK]

I found one more bug in version comparisons:
Brainworx bx_meter plugin reports version 1.18.0.0, and KVR believes that it is older than the version 1.18.0 reported as latest in KVR database.
Same with 3D Delay by Harrison: it believes that 1.0.1-1-g812e7 reported by plugin is older than 1.0.1 from KVR database.

[VladK]

Another interesting case:
NI KOMPLETE offers two versions of Super 8:
- VST plugin driven by Reaktor (last version is 2.1.0) made by NI and last updated in 2020
- Reaktor instrument (last version is 1.0.1) made by Fracture Sounds and last updated in 2025.
I have installed both, and KVR Manager reports that Super 8 1.0.1 is outdated because it knows about Super 8 version 2.1.0. I assume because it cannot separate versions for KONTAKT/REAKTOR instruments from VST plugins (and probably between entities with the same name but by different author).

[knob_monster]

This is a classic semantic versioning (SemVer) normalization issue!

To fix cases like 1.18.0.0 vs 1.18.0 and git-described tags like 1.0.1-1-g812e7, KSM's parser needs to:

* Strip build/commit metadata: Truncate everything after - or + delimiters.
* Tuple padding: Normalize comparison arrays to a uniform length (e.g., padding 1.18.0 to (1, 18, 0, 0) or stripping trailing zeros) before performing standard precedence checks.

Without strict SemVer normalization before comparison, standard string/tuple comparisons will always trigger false positives on build tags and trailing zeros.