Ethan Lee elee@codeweavers.com writes:
All of the changes are relatively easy to avoid until you get to CommitChanges, which was completely wrong to begin with. It was either wait and let more software become dependent on the incorrect function signature or break right away and get the unavoidable pains out of the way sooner than later. Either way, these ifdefs were going to happen. Breaking compatibility for one single function seemed really awful, so I tried my best to update the rest of the API to be more consistent across the board to justify the breakage a bit more (for example, properly making 2.8+ functions with the ‘8’ suffix). My hope is that this will keep us from having to break it again in the future.
You can add the fixed function with a new name, and later on deprecate the broken one. Breaking compatibility this way is bad, particularly given the current packaging situation.
What's even worse is that old code no longer builds with the new headers, so once you upgrade the library it becomes impossible to do bisects and the like. Please rethink this change.