This comes from an off-topic diversion elsewhere.
1 Like
So you are proposing a sort of debian (linux) style of releases, where people can opt into unstable, testing, and stable state? This sounds like a good idea. I think before Rack 2 there was either good testing going on behind the scenes or there weren’t many problems. It seems that things are little different, at least for now and there are obviously some common critical things passing through.
1 Like
My continuing thoughts on this:
VCV Rack, in its Pro form, is now a fully-fledged commercial product.
The impact on the commercial marketplace remains to be seen (though, in my view, such a powerful tool should, in an ideal world, take its place alongside some of the giants in this space)
With that comes a level of expectation about fitness for purpose.
For me the key observation above is from @steve - “so many different developers submitting code to the library”
As it stands, if the only thing standing between a bad code release from any of those developers and a possibly expensive and high-pressure recording session being thrown into turmoil is clicking “update all” a few seconds later, I think that has to be considered a little thin… I know I feel an unnatural urge to deal with that little red blob at the top of the window as soon as it appears 
Delayed releases to a default channel is one possible measure.
Another, quicker to implement solution could be to make absolutely clear (popup confirmation) to the end user the potential risk of pulling updates before allowing them to proceed
The online social spaces for sound production/DAWs etc. can be harsh and unforgiving places, I’m sure we all have experienced that. Reputational damage sometimes spirals out of control. Update safety might be one thing that benefits from particular focus over the coming weeks.
1 Like
well, there are multiple issues here, including getting decent test coverage before releasing to the public, and then VCV’s representation about the library.
Just thinking about this first issue, I agree with others that this is a great idea. When I developed modules I tried very hard for good quality, have thousands of unit tests, etc… But even the great me has released stuff to the rack that crashed the browser! (And, yes, VCV did roll back my plugin the the prev version and this spared most users this terrible experiences).
So, yeah, whether its LTS vs newest, or a week or two of “probation” in the bleeding edge test library before going into the “real” one. It sounds like it addresses a real need.
[edited - sorry for the typos]
4 Likes
Thanks for that contribution!
Another route to better update safety - is it feasible to have a “revert last update / batch of updates” function? One which is both responsive to crashes and also on demand? (for instance, not just when Rack blows up but simply when an undesired behaviour change in Rack or its modules has occurred)
I strongly disagree with the proposal of a user warning when updating. Even for free and FOSS software I would find this questionable but for a commercial product this is a definite no. If I pay for software I don’t expect to be the tester for code and be made liable for loss based on whether I decided to update or not. Updates shouldn’t be pushed if they are not stable.
1 Like
Do you mean the ability for a use to select a previous version of a plugin? That would force VCV to keep all the old ones, and have a database and UI in the front end. Haven’t heard anyone talk about that.
And the problem, of course, if that most users don’t know which plugin is the culprit, so they wouldn’t know what to roll back. Unless you mean “roll back the the previous stuff I had”?
is this not solvable, by simply taking a ‘snapshot’ of your current rack directory? (im assuming we have to be very careful here of saved states from an upgrade->downgrade)
as a developer, sure Im happy with branches/release tags and alike. but I suspect, many end-users would find it a bit confusing.
I think snapshots are more widely understood being used in OSs (though I suspect most users never use except in last ditch attempt at recovery)
Perhaps the revert cache could be kept locally?
It’s true that often the problem cannot be identified in a particular changed module (for instance, earlier when Hora plugin caused the browser crash, I had also downloaded updates for about 10 other plugins) - which is why I mentioned “batch of updates”, sorry if that wasn’t clear!
Indeed, very rarely does a user have only one plugin in a patch. This whole discussion kind of reminds me of the Ardour discussions about the Calf plugins, they have historically been prone to crashes and Ardour’s general response was that Ardour is stable without plugins.
It shouldn’t be too hard, automated builds are a thing and hosting a few gb for the latest (let’s say) 3 versions isn’t going to be too costly. Arch linux does a similar thing, hosts all the historical packages so a user can downgrade if necessary.
These suggestions of reversion sound useful. But there is a knock-on risk that by the time you realise there is a problem, and revert you plugin version, your patch may already contain changes that are not backwards compatible.
1 Like
Back to the issues on the other thread! Do users see these thousands of FOSS modules from hundreds of different developers as what they are (just that), or as a “product/service” that VCV provides as part of their product?
Because a lot of VCV devs are first timers, and probably don’t have much of a clue how to avoid bugs and test for them. And VCV been very explicit in wanting VCV to be a welcoming place for n00bs to share their work.
I, on the other hand, am a jerk, and have skewered some plugins viciously, and have been threatened with perma-ban for that. Spoiler alert, I stopped doing that. mostly.
It’s also hard to imagine that VCV could fund a team to test every plugin thoroughly (although I have worked at companies that do just that).
But, it I interpret “updates shouldn’t be pushed if they are not stable”, I think that can mean “should not be pushed from test library to stable library if they are not stable”. Actually, thinking about it, that is probably what you do mean! If so, sorry for the long discourse.
That’s a very good point - it wouldn’t be a very good look, would it? Agree, if there’s focus on update safety it should probably stay away from Update At Your Own Risk 
1 Like
If I was updating software, I wouldn’t do it immediately before a live stream or a studio session. And I would backup my patches first. That should apply to most software we use, I don’t see why VCVRack should be different.
Because it makes it very, very easy to do this. Most other software is not like this. Well, I guess more and more “auto update” is popular, so maybe I’m wrong here.
Why not having an option in the library (per Dev) to subscribe to stable as default and beta as dropdown or something? That way you could select which Dev you are trusting and in case something goes wrong with a release, just subscribe to stable and down-upgrade from inside VCV.
2 Likes
seems a good argument for a ‘beta’ channel for releasing.
that said, we should remember many will subscribe to beta channels for the latest and greatest, assuming there are no risks … but hey ho, as long as they are warned 
(I’d think it might need to be ‘per developer’ , as other wise a beta upgrade might bring in a lot of changes that the user had not intended… e.g. they wanted one beta module, but get a ton of others)
in linux is primarily needed because of dependancies… so you cannot just downgrade one library. this is not really the case here, modules are independent.
(besides, arch linux is not a great model in my experience… its mainly about pushing forward )
Im not saying its not possible, just not sure why you push the requirement to the servers, when the user already has a ‘stable’ system, that can been reverted too?!
simplicity and all that
I’m thinking now that I can’t think of another platform quite like VCVRack. Specifically because of the integration of the library. Its not just a store front where you can see the 3rd party offerings, but it handles and integrates the updates for you. App stores do that. But I think its much more obvious with an app store where the boundaries of responsibility lie.
1 Like
Yeah, that’s what I mean, there are plenty of users here who are happy to test things but don’t have the expertise to submit a fix so maybe it’s time to make use of the users to benefit the devs? We wish we could help by submitting code but if it helps overall just by reporting problems there are many who can do that. I think the channel idea is very good and that it should be entirely open where possible. This also solves the funding issue. I dare say that lots of bugs would still pass through testing but perhaps major ones like Rack segfaulting by using the browser would be prevented.
I know what you are talking about with what you have done, I know that you are technically right and that people should listen. Perhaps it’s not always presented in the right way but for sure your expertise is an asset.