(This is motivated by the recent issue with DirectoryManager on Android, but I didn't want to fork that thread)
Because we are using separate git repos, and even worse, releasing at different time intervals, it is going to be difficult to make any changes that require lock-step changes to platform & plugin - such as changing any public method signature, moving code around between the boundaries, etc. One strategy is to do 3 (sometimes even need 4) patches instead of 2, each one being a small step forward and compatible with all previous steps: - Patch (A) to lay the groundwork for some future work in (B), and bump the version MINOR - This version of (A) should be both backwards or forwards compatible with versions of (B) - This can often be difficult, such as supporting various function signatures at the same time without changing namespaces etc. - Patch (B) with your feature, taking advantage of (A)'s groundwork above. Bump the version MAJOR, and the version dependency on (A) - Patch (A) to remove/deprecate the old code, bump the version number again, this time with a MAJOR ( The fourth patch is sometimes a necessity to lay groundwork in (B) before you can lay groundwork in (A) ) I've had to do this on projects before, and its really not fun. Another option, is to leverage version dependencies with a little speculative planning: - Patch (A) and (B) in one patch, bump the MAJOR and update dependencies (this is basically what Andrew tried to do) The issue is that (A) and (B) aren't released to the world at the same time, so you have to speculatively bump version dependencies for platform/plugin which may not be released yet. This *requires* a plugin repository which can supports version deps, which we don't have right now. Until then, we should stick to the first strategy (actually for now all plugins must work with 3.0.0 I think because of plugman repository?). Any other thoughts/suggestions, aside from "just don't change anything"? -Michal