I see that the Plugin Manager today shows 1.0.0 plugins, if they exist for a particular plugin, or the older version is shown. I assume the 0.6.0 will go away once 1.0 “ships”?
I might (or might not) make v0.6 plugin library builds in the future, but I’m not spending any time on it right now.
Rack v0.6 uses the v0.6 version of the server API, which serves v0.6 plugins when their latest versions are requested. It will remain active for at least a few months.
I guess things will sort out, but at the moment it’s pretty confusing to go to the plugin mangers with Rack v 1.0. I see tons of things listed, but I can’t download the vast majority of them, because they aren’t compatible with 1.0.
And I assume that if I sort by number of downloads, a whole bunch of 0.6 plugins that will never be ported with still be in the top slots?
It would probably be “better” if each version of rack only listed plugins that would work with it?
5 Likes
For what I can see, the best thing to sort out versioning in the Plugin Manager appears to be clicking on the Build updated tab. This way 1.0 plugins stay on top.
1 Like
I can understand Andrew not wanting to maintain a plugin manager for both 0.6 and v1 but agree things will be confusing for newcomers once the PR push brings bunch of new trialists.
On a personal basis I now maintain both a 0.6 installation and a v1 version too (brute force approach). There are far too many modules I rely on that are unlikely to be updated to v1 anytime soon.
Do you really think people coming to VCV Rack are going to sort that way?
Of course - one reason VCV is so great it that Andrew picks his work very carefully and pragmatically. I really admire that. But I don’t think maintaining two is much work. A single “manager” with two different HTML renderings depending on the version of the client that is coming in? It’s already dynamically generated via JS anyway. But of course it is work.
I do, too. But it would be nicer if when I went there with my different versions I could see what’s appropriate for either.
Oh sure not that! I was only appointing the only hint I can figure out at this moment to get some sort of grouping for the two major versions in the actual state of the Plugin Manager.
I agree that distinct views for peculiar Rack versions is the most desirable thing, and I’m hope we’ll get there soon. A simple filtered view - defaulting to the last public major version for “guest” users, or set to the Rack client version forwarding the request for registered users - should be sufficient. A select box could then allow to switch the listings to match a specific version number.
Incidentally, under the hood one can already get the raw feed of v1 plugins, like this: https://api.vcvrack.com/library/manifests?version=1
A multi-versioned Plugin Manager front-end could surely prove to be a necessity (and a strategic choice), if in the next months users should differentiate and spread among the two different versions - I mean, some users, and the new ones, will probably want to get/update to v1 in the first instance, others and some consolidated users could stick to v0.6 or mantain parallel installs. And, though it’s VCV-sci-fi at the moment, if v2 will really ship roughly at the end of the year, there could be an option to mantain three versions at the same time.
Personally, I’m following the brute-force approach me too, mantaining both two “branches” of Rack, v0.6+ and v1.0, both for the source code and for the installed executables. I do so for “educational” purposes, and to be able to inspect/play with plugins that won’t be updated in the short, or even that will possibly never get an update (something similar happened in the transition from v0.5 to v0.6). Also, I love tracking the evolution of my favorite softwares 
Obviously, like you already noted, adjusting the PM to fit this scenario can appear to be not so… ehm… dizzy… but it’s a job anyway!
1 Like