We are currently trying to separate our codebase that is shared across plugins in order to be a more flexible when updating one or another part of the plugins functionality.
As of now, we have one big repository that hosts a couple of JUCE modules that is added to the plugins via git submodules. The idea now would be to split the big repository into a couple of new ones, each just hosting one single JUCE module. This means that a plugin would have a couple of submodules instead of one.
In principle this already works fine, but I can see problems coming up in the future, namely when dealing with inter-module dependencies. While simple dependency management is already possible with the current JUCE module format, it can only handle make sure that another module is present.
The approach that I’d imagine however would require the module system to make sure that another module is present with a given version, or maybe even a version range. This would probably require a change to the module format, I’d propose something along the following lines:
... dependencies: email@example.com, juce_audio_formats@<7.0.0, juce_events@[6.0.2..6.1.0], juce_gui_basics@>5.4.1 ...
If a dependency isn’t met, then a compilation error could arise, telling the programmer to update a certain module. I think that this could be a very useful addition to the module format.
Do you think that this is feasable?