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.