Every now and then, the JUCE team (well mostly me really ) introduces a bug into the JUCE code which can only be fixed by a version breaking change to the plug-in code.
By “version breaking”, I mean that there will be some sort of incompatibility with old versions of your plug-in - for example, a Cubase project saved with an old version of your plug-in may fail to load when using a newer version of your plug-in compiled with a newer version of JUCE. Examples of such “version breaking” fixes are here and here.
To avoid only talking hypotheticals, let’s take the former example: we noticed that some hosts don’t like it when the parameter ids are negative. In fact, the VST3 SDK strongly suggests that parameter ids should only be positive. Let me be clear: allowing negative parameter ids was an oversight and a really unfortunate bug introduced by the JUCE team.
But how to move forward in such a case? The only workaround is to avoid negative parameter ids in JUCE which can easily be fixed. The downside is that the fix will “version break” your plug-in.
Therefore, JUCE’s current policy is to apply the fix by default - but add some sort of option to opt-out of the fix.
The reasoning behind this choice is the following:
- If there is a bug in JUCE that can only be fixed by “version breaking” we need to push this out ASAP. Otherwise, more and more plug-ins will come into the market that are not only potentially broken - but hard to fix without “version breaking”. Therefore, the default must be that the fix is applied.
- Some people have suggested to always ask the user if the bug-fix should be applied or not. But this is overly confusing for a vast amount of JUCE users. Many users might not even understand the technical details of the bug - nor do they need to. As the JUCE team introduces more and more “version breaking” changes (this is bound to happen), the number of “questions” the Projucer would need to ask will become overwhelming. In addition, the JUCE users that are likely to run into any “version breaking” problems have already released products to the public and therefore are usually more experienced JUCE users and have mostly interacted in the forums before. It’s easier for these developers to find the fix to a specific “version breaking” problem.
What are your thoughts on this? Any suggestions on how we could improve when we fix these types of bugs?