If you mark min version as 2.4.0, what happens when a user with 2.3.x tries to use it? i.e. what is the end-user experience?
My understanding is that it will just not download the new plugin, and the user will stay on the prior version until they update their Rack to 2.4.0. For new users this would be ok also, since they will download the latest version of Rack, so no problem there. But if a 2.3.0 user does not have a certain plugin, and they subscribe to that plugin, and that plugin happens to have a minRackVersion of 2.4.0, then they will not get the plugin at all. This is all speculation from me looking quickly over the Rack commits, so hopefully @vortico or @cschol can explain a bit about how this mechanism will work. We’ve seen the announcement for Rack 2.4.0, the recommendation to use the latest toolchain and the 2.4.0 SDK, and were instructed to use this to make new builds, but I’ve not seen any dev recommendations regarding minRackVersion, hence my initial question regarding backwards compatibility of 2.4.0 plugin builds and the minRackVersion mechanism.
It looks like 2.3.0 will still download a 2.4.0 SDK plugin and fail even if minRackVersion is set to 2.4.0, which makes sense, as 2.3.0 isn’t going to know to look at the minimum supported version yet.
Why would 2.3.0 fail to load all 2.4.0 plugins?
Yes, but the library-side might know that a 2.3.0 rack is requesting a 2.4.0-built plugin and simply not show it as an upgrade option, and not allow it to be downloaded.
2 Likes
I think this other thread answers some questions, monome has this in their manifest:
“minRackVersion”: “2.4.0”,
and it does this:
1 Like
I’ve gotten user reports of both behaviors now (on the monome plugin.) The library not serving 2.4.0 plugins to 2.3.0 would be preferable!
1 Like
Excellent, my question is getting simpler now: does anyone who builds a plugin with the 2.4.0 SDK necessarily have to put a minRackVersion of 2.4.0 in their plugin manifest? Or is this only mandatory if they use new 2.4.0 Rack features, such as the prefer-dark-panels setting?
1 Like
Thanks to this thread, I realized that indeed my monomes had vanished. I did update them, and the update went normally, but the plugin load silently fails at VCV startup (there is a log entry, however, on that failure). Luckily I had the latest one that doesn’t require 2.4.0 backed up, just threw that in the plugin folder and it works (checked the changelog I’m not missing anything dramatic, eh).
No, but:
Yes
(From what I understand now)
1 Like
So any thoughts on sort of a reasonable timescale to set this and expect people to upgrade? I have dark panels on all my plugs which could use this feature, but I also have lots of users who haven’t upgraded since the release 5 hours ago 
Just curious what other devs are thinking as to how long to let things settle down before pushing a release
The next version of surge won’t be until the late fall if then, but airwindows updates pretty regularly and could just follow this setting easil and remove some complexity, as could baconplugs.
2 Likes
In my case, I will push a new Impromptu within the week that uses the new global dark setting in Rack. I will set my “minRackVersion” to “2.4.0”, just like Fundamental now does. My reasoning is that if Fundamental does it, then it’s fair game for any dev to do it like this also if they wish.
will that break your 2.3.0 users or just leave them on the old version? That’s the thing I’m unclear on
It will leave them on the old version, it won’t break their setups. They will have the red update dot for Impromptu, and they can even try to update if wanted, it will just not download the new version and they will keep their old version of the plugin. That may sound like an un-optimal case that the red dot would always be there for them, but right next to it in the other menu they will also have a red dot to update Rack itself, so not much harm the way I see it. Both red dots (Rack and plugins) will be a good incentive to make the update to Rack 2.4.0 I think, which should be a good thing. Just perhaps those with a critical setup for a live set or something would like to stay on a prior Rack version, but for the rest of the users, I think updating should be something they wish to do.
1 Like
From user reports and my own observations, third-party plugins that are built against 2.4.0 [edit: and use 2.4.0 features] do break when installed by 2.3.0. As people have already mentioned in this thread, the monome 2.1.5 release specifies "minRackVersion": "2.4.0" but 2.3.0 will still download and unpack it, and it fails to load on the next restart.
I don’t see anything in the 2.3.0 code that would keep it from downloading a new version of the plugin. The request to the library only includes the major version number, and nothing in 2.3.0 checks the minRackVersion property.
Fundamental/VCV Rack Free does currently behave as you describe; Rack 2.3.0 will download the update but then restore the original, working version on next boot. But I believe that’s because of the special repair code for Fundamental that has been in Rack for a couple of years.
1 Like
Oy vey …
Interesting, thanks for following up with this, I’ll have to look deeper into this then, since in the test I ran with ShapeMasterPro, I did not get anything like you mention regarding monome breaking.
Surge 2.1.8.0 is built with the 2.4.0 SDK but doesn’t use any 2.4.0 features; and it loads without problem in rack pro 2.3.0. It seems from the monome experience that if you do that it breaks existing users who have not upgraded to 2.4.0 which makes sense and why the min field is there.
I want to help encourage people to 2.4.0 but surge is a pretty popular package; want to make sure i stage this in a way which doesn’t get our discord and this message board loaded with support requests!
4 Likes
I’m noticing the exact same behavior with ShapeMasterPro, I did not use 2.4.0 features, so I didn’t put the minRackVersion in my plugin manifest, it was built with the 2.4.0 SDK, and it works well on both pre-2.4.0 and 2.4.0 Rack.
I’m thinking the monome case must be a corner case of some kind, since if Andrew put the minRackVersion option in there, then I assume that one of its uses is to allow a graceful transition for using the global panel theme option in Rack 2.4.0. I assume that the intended purpose is to not break pre-Rack 2.4.0 users’ setups, all the while allowing upgrades to continue forward.
stage this in a way which doesn’t get our discord and this message board loaded with support requests!
@baconpaul I’ll do Impromptu and let you know how it goes!
Monome 2.1.5 is built against the 2.4.0 SDK and uses the global panel theme option.
Having minRackVersion will be great for the next breaking API change, but since 2.3.0 isn’t aware of it, it appears we have to deal with one more rocky transition.
1 Like