Out of curiosity, why did you choose to add the new method with a temporary name? Since this is C++, you could have added "int SetOutputVolume(float volume, bool allow_eleven);" without removing the "old SetOutputVolume(float volume)", no?
Thank you! You are right, the temporary name isn't necessary in this case because of method overloading. You will only really need it in some cases, for instance if you change the return value from string to int, without changing the rest of the method signature.
Is the WebRTCAmplifier interface on the chrome side or the webrtc library side. If it on the third party library side; managing "interface definitions" may not always be practical. However if this interface is on the chrome side then I can see how this can be help
It's on the WebRTC side. We happened to control WebRTC in this case as well, so we could update the interface as we wished. If the library API is managed by someone else, you're going to have with to work with them (or submit patches if the library is open-source). It might not be worth it to set up FYI bots if interface changes are hard to do.
If the third-party library is controlled by someone else and widely used, they should already be using the API prime directive. I think it's common to not remove or change methods in a published interface; if so, the method is deprecated and left remaining for about a year so all clients can update to use the new method. In that case your product should still build at HEAD of the third-party library and your FYI bots will work.
What's Chromium's policy on handling failing FYI bots for third-party libraries you're not in control of? I'd be specifically curious to know if you have specific people or teams assigned to each library (or groups of) that would be responsible for dealing with breaking changes. Also wondering how you decide when to deal with them. I'd guess it's a case-by-case matter, but maybe you've come up with something more sophisticated.
I don't think we keep FYI bots for libraries we're not in control of, but if we did we would try to contribute fixes to that library (if we found bugs) or work with the people controlling the library. Ultimately I don't think the control question is the most important, but rather how fast the library is changing and how tightly integrated it is with Chrome.
Each third_party library has dedicated owners and a description (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libphonenumber/README.chromium for instance) of how it's used in Chrome. The update policy varies and is in the control of the owners - stable libraries may not update that often. It would be interesting to plot out the change frequency for each library in third-party. WebRTC and Blink are updated almost daily whereas other libraries may not be touched for months).
Great article!
ReplyDeleteOut of curiosity, why did you choose to add the new method with a temporary name? Since this is C++, you could have added "int SetOutputVolume(float volume, bool allow_eleven);" without removing the "old SetOutputVolume(float volume)", no?
Thank you! You are right, the temporary name isn't necessary in this case because of method overloading. You will only really need it in some cases, for instance if you change the return value from string to int, without changing the rest of the method signature.
DeleteIs the WebRTCAmplifier interface on the chrome side or the webrtc library side. If it on the third party library side; managing "interface definitions" may not always be practical. However if this interface is on the chrome side then I can see how this can be help
ReplyDeleteanand raman
It's on the WebRTC side. We happened to control WebRTC in this case as well, so we could update the interface as we wished. If the library API is managed by someone else, you're going to have with to work with them (or submit patches if the library is open-source). It might not be worth it to set up FYI bots if interface changes are hard to do.
DeleteIf the third-party library is controlled by someone else and widely used, they should already be using the API prime directive. I think it's common to not remove or change methods in a published interface; if so, the method is deprecated and left remaining for about a year so all clients can update to use the new method. In that case your product should still build at HEAD of the third-party library and your FYI bots will work.
What's Chromium's policy on handling failing FYI bots for third-party libraries you're not in control of? I'd be specifically curious to know if you have specific people or teams assigned to each library (or groups of) that would be responsible for dealing with breaking changes. Also wondering how you decide when to deal with them. I'd guess it's a case-by-case matter, but maybe you've come up with something more sophisticated.
ReplyDeleteThanks!
I don't think we keep FYI bots for libraries we're not in control of, but if we did we would try to contribute fixes to that library (if we found bugs) or work with the people controlling the library. Ultimately I don't think the control question is the most important, but rather how fast the library is changing and how tightly integrated it is with Chrome.
DeleteEach third_party library has dedicated owners and a description (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libphonenumber/README.chromium for instance) of how it's used in Chrome. The update policy varies and is in the control of the owners - stable libraries may not update that often. It would be interesting to plot out the change frequency for each library in third-party. WebRTC and Blink are updated almost daily whereas other libraries may not be touched for months).