Gurchetan Singh <gurchetansi...@chromium.org> writes: > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <h...@alyssa.is> wrote: >> >> Gurchetan Singh <gurchetansi...@chromium.org> writes: >> >> > In terms of API stability/versioning/packaging, once this series is >> > reviewed, the plan is to cut a "gfxstream upstream release branch". We >> > will have the same API guarantees as any other QEMU project then, i.e no >> > breaking API changes for 5 years. >> >> What about Rutabaga? > > Yes, rutabaga + gfxstream will both be versioned and maintain API > backwards compatibility in line with QEMU guidelines.
In that case, I should draw your attention to <https://crrev.com/c/4584252>, which I've just realised while testing v2 of your series here breaks the build of the rutabaga ffi, and which will require the addition of a "prot" field to struct rutabaga_handle (a breaking change). I'll push a new version of that CL to fix rutabaga ffi in the next few days. Since this is already coming up, before the release has even been made, is it worth exploring how to limit the rutabaga API to avoid more breaking changes after the release? Could there be more use of opaque structs, for example? (CCing the crosvm list)
signature.asc
Description: PGP signature
