Hello,
following the recent V5.2.1 tag, we (my company) decided to migrate to this version, as it includes VST evolutions we need.
During the migration process, we were surprised that compilation of every of our audio plugins failed due to interface breakage.
Indeed, the commit a7e3339 “Got rid of some very old legacy VC6 workaround typedefs” removed several typedef for some classes inherited in plugin’s code.
Facing the Juce version number (5.2.1 in this case) we expected no interface breakage as depicted in the vastly adopted versioning scheme here : https://semver.org/
Indeed, such interface breakage should result in a 6.x version number.
Moreover, in the process to find out the source of the breakage, it was painful to identify the commit version as the develop branch seemed to be merged in fast forward mode on master.
A non fast-forward git merge (especially from develop to master) could be a great help to have a global picture of changesets occured between two Juce version.
Maybe a git workflow inspired from http://nvie.com/posts/a-successful-git-branching-model/ could help in some way to get a better separation of developments between thirdparties evolutions (VST), inner code refactoring …
Please provide your advice and feedback around Juce version management on both versioning number and git workflow sides.
It’s a very easy breakage to fix - simply replace *Listener with *::Listener. The former class names have been discouraged for years.
Why are the commits on the master branch causing you trouble? It could be tidier, but the releases are tagged, so they’re pretty easy to navigate to or look at the differences between. If anything having a linear history makes using a tool like git bisect easier.
The simple answer is that JUCE does not follow semantic versioning. Instead, we have a BREAKING-CHANGES.txt file in the root directory of the repo which we keep up-to-date. We also always announce the addition of a breaking change prominently on the forum.
We normally have a few minor breaking changes with every minor and major JUCE release. We therefore, recommend everybody to read the BREAKING-CHANGES.txt file before updating JUCE.
Major breaking changes will always be announced well-ahead and will be marked with #pragma deprecated (or similar) in the code several months before the actual change (this is what we did with the Listeners for example).
With regard to our git workflow: the timeline of our develop branch should always be linear. When we release, we simply fast-forward master - or - if there were urgent hot-fixes which were both applied to develop and master - we merge develop into master.
Therefore, when bi-secting, simply checkout the respective release commit (release commits always have the following commit message: JUCE version x.x.x ) on develop and then bi-sect there.
