My natural tendency is to publish frequently, at least when I have new additions worth noting. But I don’t really know if updating modules adds a lot of workload to the library maintainers; if it did, I’d be inclined to do fewer of them so as not to test their patience and needlessly bog them down just because I love the possibility of feedback from doing a new version.
Thoughts? Especially interested in the opinions of the maintainers themselves, of course, but has anyone been told, hey, don’t release every week, you’re clogging the pipeline?
For plugins where we build from source code (such as open-source plugins and proprietary plugins where we’re given the source), we review all the code in the diff. Our effort is proportional to the size of the diff, plus around 10-15 minutes average for building and informing the developer of any build issues. Any update that makes users of your plugin happy is worth this time.
We update plugins every week or two, so if your update requests are more frequent than that, we’ll just review/build your latest version.
I’m happy to hear that you’re doing reviews <stares into space thinking about the readability of my code>. I would typically wait anyway until the previous version had gone live before updating the request thread, except for that time when I found a potentially Rack-crashing bug in my module.
But if the effort is roughly O(lines changed), then I think my current pace is fine. Thanks!
as a curmudgeonly user, I will say that if I subscribe to a plugin, and it updates every week with a long list of bug fixes, I think “wow, there sure are a lot of bugs in this plugin”, and then I don’t tend to use it much.
What some developers do when actively working on modules is to put builds up on GitHub for users to download/test/feedback on. Then when a module/plugin is in a stable state and ‘finished’ (or at least finished for now…), publish it to the library.
There are quite a few users who say they only download modules from the library and not GitHub because they want a stable and complete experience - they don’t want to use modules that are in alpha/beta stages. They expect modules in the library to be complete/finished.
Putting ‘work in progress’ builds up on GitHub allows those users who are happy to play with and test unfinished modules to do so and keeps those users who only want to use stable/finished modules from the library happy too.
YMMV of course and I’m just suggesting this as a possible approach.
This technique also gives you a good rhythm. “Ok so our next release is in 10 weeks what do we want to put in it and let’s look for testers in 8 weeks” type thing, but some folks run every nightly and give amazing bug reports (we just got one this morning on a bug I wrote yesterday afternoon and fixed before my coffee) so the system does indeed work.
@steve Yes, I did that for my first two modules, when I was getting my sea legs for VCV Module creation. It was certainly very helpful.
In this specific case, while I am still actively working on it, I don’t consider BASICally to be a work-in-progress in the sense that it doesn’t currently do anything useful. Far from it! I’m just from the “users can’t tell you what want until they see it running” school of experience. And the feedback and encouragement has been quite useful for the prioritization of what to add first, and influenced my pondering of what to add or not. Not to mention clever ideas that never would have occurred to me.
That said, I am about to reach out on that announcement thread and request feedback on some ideas I have. So that’s another advantage to releasing a smaller version first; you have an (admittedly biased) set of users to bounce ideas off of. Since is this just a solo personal project, I find that of great value; I’ve proven myself to be mistaken so often in API and UI design that a small Greek chorus saying, “Oh, I wouldn’t do that…” takes some of the stress out of making a new thing.
@baconpaul Having people potentially testing every CL I submit is, interesting. It reads a bit more like having a job than I’m entirely comfortable with at the moment, but I’ll ponder the idea more…
Yeah the surge vst does this as do several of our library modules.
I think the trick with nightlies is to make the git hash part of your version and insist nightly users use it in bug reports. But it also means your commits should try and not be obviously wrong which is a standard I missed twice in December, but then was able to fix once someone let me knew