On Thu, May 2, 2019 at 12:29 PM Ethan Lee elee@codeweavers.com wrote:
Those names definitely look messy, but not quite messy enough… I’ll keep thinking of a good name, but for now (at least for demonstration purposes) I’ve gone ahead and used ‘BADABI’ to lay out how this is going to go down:
https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135...
https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135...
So I’ve added the fixed functions and that’ll work for the rest of 2019 - this can safely be used for all of Wine 4.x and 5.0, and the function used by 4.3 through 4.7 (or 8 or 9, depending on when you want to move to the corrected function) can still build against the old function. It won’t work (and absolutely positively never will and never could have worked, just to emphasize one more time), but it’s at least there for compilation purposes. By the time 5.0 is out the proper function will be available and the 5.x series can use the new function, while 5.0.x maintenance releases can continue to use the BADABI function safely without having to worry about it getting lost before 6.0 is out. Once 6.0 is out, both the stable/unstable branches of Wine will be on the right function and the old functions won’t apply at that point.
If someone really _really_ needs to do a multi-year bisect, they can pass --disable-faudio and save themselves the build time. If the XAudio2 subsystem is what’s being examined, they’re most likely looking at FAudio and not Wine.
-Ethan
Labeling the newer function as BADAPI strikes me as even worse. I'd expect something labeled BADAPI to be proscribed rather than prescribed.
I think this approach is a matter of looking at compatibility the wrong way. I think it doesn't make sense to treat the erroneous function as so wrong that it needs to be completely removed from the public library, nor I do see why it's absolutely necessary that the correct implementation of CommitChanges actually have the exact name CommitChanges(). API compatibility isn't something you keep as a temporary measure until you think that everyone has updated your library; it's something you keep for as long as possible, until the combined weight of design mistakes and errors makes it more worthwhile just to scrap the whole interface and recreate it. Incrementing the major version shouldn't be something you do every year just because time passes, but rather something you do only when you have to. (That's not to say you shouldn't call it 20.x and 21.x etc. after the year, but the library major version should remain the same.) An incorrect parameter signature doesn't make that necessary, inasmuch as FAudio isn't an ABI-compatible drop-in replacement for XAudio but rather a tool to recreate its logic and to allow easy porting. Anyone who's interested in porting can rely on documentation to tell them that CommitChanges() is deprecated in favor of CommitChangesBySet(), if the missing parameter isn't already enough of a clue.