On Fri, Apr 9, 2021 at 4:57 PM Weston Pace <weston.p...@gmail.com> wrote: > Note, these problems technically exist now with the concept that any > language can release a patch at any time. Also, since Rust isn't > directly compiling against other Arrow libs and we are only talking > about interoperability it's probably not going to be too big of a > deal. Still, worth giving some thought ahead of time.
It looks like the requirements we have here are: * Catch integration issues between development trunks between two repos as soon as we can * Avoid development trunk of a repo from blocking releases of another repo How about we always run the integration tests against the latest releases in both repos by default. On top of that, we run integration tests in the Rust repo against nightly Arrow to help catch integration issues between development trunks. In the Rust repo, we could enforce the rule that a Rust release will only be cut if the release candidate passes the integration tests for both the latest released and nightly Arrow code base. This way, we will still be able to catch integration issues between development code trunks on a daily basis. It would be Rust developers' responsibility to report these integration errors back to the main repo. >From the main Arrow repo's point of view, there is less work since it only needs to care about the last stable Rust release. >From the Rust repo's point of view, we are effectively trading extra maintenance burden for more release flexibility. Thanks, QP
