What happens to external modules when JUCE changes the API for a function? I’m thinking about the recent changes to Array, for example, which broke VFLib.
Well, I guess you’d need to update the external module to match it…
This could turn into a headache if the JUCE repository gets both an API-breaking commit as well as a vital bugfix commit. There would be no sane way for someone to pick up just the bugfixes and hold back the API changes.
Would it be possible to have two branches of JUCE? We could keep “master” the way it is and have second branch “stable” where bug fixes and non API-breaking changes are cherry picked?
I think that if we want external modules to flourish there needs to be some version discipline. Perhaps minor releases promise no API changes (but major releases can change APIs)? Or else someone who is using JUCE and several external modules will run into headaches when a bug is discovered in JUCE and there’s no way to pick up the fix without also getting JUCE changes that break the external modules.
No, I really don’t want to have to maintain two branches, my brain is too full already.
Well I think if you don’t want to maintain two branches there needs to be a little more stability for APIs. Lets take the Array changes. A function was renamed to two different routines (one of which is findFirstOccurenceOf if I recall).
Instead of breaking the API we should have just added the two new functions for the minor release, people could migrate over and there could be a note in some CHANGELOG or VERSION / README file indicating that the old function is going away in the next major release. Then when the major version is bumped up, delete the old functions.
This way there is an assurance that JUCE APIs wont change except for a major version increase.