v0.6 Plugin release preparation

[cschol]

@AndrewBelt

Inspired by this thread in the Rack tracker:

1. Right now, I am moving any plugin that is confirmed to be working on all platforms and adhering to the new Makefile template (RACK_DIR!) to v2. Even after launch, I expect some plugins to not be updated. We would continue to monitor their state and move them over as soon as they are updated. Does this match your expectation?
2. A lot of plugins define their version as 0.6.0dev right now. Do the developers need to update the version before release to remove the dev suffix? If yes, we would start pinging developers that are already included in v2.
3. Are you planning on providing a developer guide for updating the community repo with git submodules and providing PRs for their plugins? I expect there to be confusion with developers who are not familiar with git submodules. I can draft a guide.

[AndrewBelt]

1. Yes, I will devise a more organized workflow of each VCV community team in the next few weeks.
2. Yes, the dev version was a mistake. There are only types of versions: Those which work with an API version of Rack, and those that build against some commit hash of Rack master. From now on, the latter should be versioned simply VERSION = master and will not be distribute in any sort of package manager.
3. Only the members of some VCV community team should be messing with submodules. Plugin developers will not be responsible for updating this repo, only for notifying version updates and changes to their metadata. These will be jobs for the Library Team.

[cschol]

1. OK. I'll continue until the new process is in place.
2. For clarification: do developers need to update their plugins to v0.6.x then? Or is that versioning done in the package manager?
3. Ah, got it. Thanks.

[AndrewBelt]

2. Yes, all developers should change their VERSIONs to 0.6.* at this time.

[cschol]

Got it. I'll get started pinging v2 developers to update and pull the updates into a PR.

Update: 13 out of 37 are correct already.

[gbrandt1]

hi, sorry i don't get how the PR for the 0.6 test works. do i have to fork the community repo? where do i provide the clone URL? thanks

[djpeterso23662]

When writing up guidance to the developers, would it be possible to go with editing the json on the GitHub website, rather than cloning the Community repo and doing a pull request from the clone? I think this would cut down on the large number of unnecessary clones of Community and be a better use of time and energy. Thanks!

[AndrewBelt]

@djpeterso23662 I was considering that, but that prevents us (the VCV community) from making changes ourselves. From experience in the last few months, only 25% of plugin developers nailed the format perfectly, which is much too low. (We need 100%)

[cschol]

Bidoo plugin has some quirks, that are affecting the build of v2:

• Needs make dep (to build mpg123 dependency). I think that it OK, but it requires another step to be run for just that plugin before make dist_all can run.
• Links against static library libcurl.a provided by Rack in dep directory. This fails when using the Rack-SDK. I am thinking to notify the developer that they should provide their own dependency inside the plugin.

Thoughts?

[AndrewBelt]

I've added libsamplerate to the Fundamental build system, so you can use this as an example, ~~but it's not super elegant.~~ It is now pretty elegant. I would recommend this for all libraries. https://github.com/VCVRack/Fundamental/blob/master/Makefile I'd say wait on Bidoo. Maybe there's a way to hack Windows around the DLL loading problem.

[cschol]

Awesome. Thanks. I will present that example to some plugins that use libsamplerate right now.

Maybe there's a way to hack Windows around the DLL loading problem.

Not sure what you mean by that. Will the static link not work for Windows?

[AndrewBelt]

On Linux and Mac, the following is possible:

• Rack loads libcurl using linker information at boot
• Rack loads plugins/Fundamental/plugin.* dynamically
• the plugin uses symbols from libcurl

On Windows, DLLs can't talk to sister DLLs, only the main program. Otherwise this problem would be easy to solve by just having Rack load a bunch of common DLLs. An option is to statically link libsamplerate, libcurl, etc, but for some it's harder than others.

[cschol]

@AndrewBelt After the current PR #369, all plugins in the v2 repo build and package successfully with make dist_all on Linux.