5 ms·

> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer resp

by abenga 2y ago

> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that. This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? > This is already happening with C development anyway,... As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.

CFLAddLoader 2y ago
> This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release? I'm pretty sure they are just asking for emailing. Just a short shift to getting changes in advance some of the time rather than none of the time. It didn't sound like they were asking to cross the divide from Partition Tolerance + Availability to Partition Tolerance + Consistency, merely shifting things a step in that direction (I think the CAP theorem applies everywhere).