While adding LV2 support to a plug-in host, I noticed that PluginDescription::version always comes back empty for LV2 plug-ins, even though the LV2 manifest clearly has version info in it.
On the plug-in side, JUCE writes version info into dsp.ttl correctly, but on the host side, LV2PluginFormat::getDescription() never reads any of that back out. It populates all other fields but result.version is simply left as empty.
I think it might be better to read the doap:revision field instead though, which JUCE populates with JucePlugin_VersionString.
Because of LV2 not having any lv2:majorVersion field for some reason, a JUCE plug-in with version “1.2.3” is read “2.3” with the current fix.
Perhaps we could check doap:revision first and construct from minor/micro version numbers as a fallback?
I’m not sure about this. The lv2 version fields are the ‘official’ way for the plugin to communicate its version information. There’s no major version because all plugins with the same lv2 URI must be compatible. Making a breaking change that would require a new major version implies that the plugin URI should change.
I suppose the issue is that there’s some tension between the JUCE version number, which is somewhat freeform, and the semantics of the LV2 version components, which have specified meanings. Using the JUCE version number for an LV2 plugin requires that the JUCE versioning also obey the LV2 versioning rules.
The docs here have more information about LV2 versioning.