I know. But adding symbols to (e.g.) SDK version 2.3.0, and a developer using those new symbols in their plugin, will prevent the plugin from running in Rack versions lower than 2.3.0. That’s my whole point in what I was saying.
That is correct, but this part isn’t:
Adding new symbols is adding “functionality in a backwards compatible manner”, so the minor version should be incremented, not major.
It depends on what you think “backwards compatible” means. In the example I just gave I would consider backwards compatibility to be broken, because the plugin is no longer compatible with anything older than 2.3.0. And that’s why I said that if it’s your policy that that is fine it should be stated very prominently on the website, so that users know it and that every developer knows it, and should make up their mind whether their plugin should only run on latest Rack or on all 2.x Rack versions.
You’ve got it backwards. What you’re thinking of is called “forward compatibility”.
The Nintendo Wii can run GameCube games (backward compatibility), but the GameCube cannot run Wii games (forward compatibility).
Similarly, Rack 2.3.0 can run all plugins compiled for Rack 2.0.0 (backward compatibility), but Rack 2.0.0 cannot run all plugins compiled for Rack 2.3.0 (forward compatibility).
1 Like
And that’s what I would encourage you to document loudly, because I guarantee that 99% of users don’t know that, and 90% of developers don’t either. It’s not obvious unless you say it.
1 Like
@LarsBjerregaard , I think that there have been new symbols added in many (possibly most) of the point releases, and IIRC I don’t think it’s been an issue up until now (where there was a not-strictly-additive change).
Freezing the API until the next major release would either slow down API development dramatically (which I don’t think anyone wants) or require major releases to adopt the current cadence of minor (point) releases, in which case the concept is meaningless…
Perhaps as a complement to some form of versioning metadata in the manifest, Doxygen could get comments about “added in version X.Y.Z” (there may be some of this already, I didn’t check). But it seems as though devs have been doing pretty well with the no-forward-compatibility regime so far.
Agreed, because 99% of Rack users don’t read the manual. I can lead a horse to water but I can’t make him drink.
2 Likes
Right. The vast majority of users are going to respond only to application behavior (which is why the optimal solution for old versions would seem to be “don’t load plugins that depend on new APIs, and tell the user to upgrade if they want to use those plugins”)
1 Like
Right, you got me there, because as someone who has read every single paragraph of the manual, more than once, I had forgotten that wording is actually in there. So when I say prominently I’m thinking directly on VCV Rack 2 - Virtual Eurorack Studio
Something like “Keep your version of Rack updated regularly, as never versions of plugins might not work with older versions of Rack”.
I still don’t think breaking forwards-compatibility on a regular basis is a good idea, but that’s your call.
The part I don’t quite understand is, the Versioning manual entry says (emphasis mine)
“A minor Rack update adds (but not removes or changes) symbols to the plugin API and ABI”
however, in requiring us to use setImmediateValue() to get the prior behavior of setValue(), and setImmediateValue being a new symbol, it seems that it does not follow the original intention to not change existing symbols on a minor Rack update.
My comment is not meant in an accusatory nature, it is truly intended to help understand how changes work in Rack.
Cheers,
Marc
P.S. thank you Andrew for participating in this discussion, just like the good old days, it was refreshing to see this out in the open.
3 Likes
No problem, but I’m hardly discussing anything, just reiterating what I’ve written years ago. The best way to suggest changes to VCV products is to contact VCV - Support. It allows us to organize and prioritize requests from all users and developers, not just those posting on forums or social media.
I think this is the correct way to think about it Marc. The problem isn’t that set immediate value was added it is that set value was no longer fit for the purpose you were using it for in 2.2.*
There was no single function in the api which provided set value behavior in 2.2 and set immediate value behavior in 2.3 so your choices were break 2.2 users, break 2.3 users, or copy the function body
4 Likes
I think the problem here @Vortico is that Marc’s plugin shows this to be false. If you compile it with 2.2 you don’t work with 2.3 (that’s the bug up thread) because set value has changed. If you remediate that using the api you abandon all users on 2.2 and so on.
We have a solution (don’t use the api copy the body) but I hope this helps you see why folks were a touch off balance?
6 Likes