I've been thinking about the process here, and I'd like to propose an alternate path. As I understand it, currently the process is:
1. Approve the Rust API as a stable API 2. "Release" Rust API as part of a new version of the ADBC format 3. Release Rust libraries in tandem with other ADBC libraries, matching their version number. On step (1), I don't think we have enough developers yet working on Rust ADBC to get adequate feedback on the API design to make something we want to be stable. I've had some time to accumulate work in WIP PRs, but still don't feel fully ready to declare any stable API. Also on step (3), it doesn't seem obvious to me there's a benefit for Rust to matching versions of other ADBC libraries. Rust's release process is lightweight enough where it's not much additional effort to release it separately. I would be willing to do that, at least initially. So I'd propose: 1. Plan to merge Rust API as "experimental", and not stabilize it until a little later. TBH I don't even think having a stable API in Rust is a big deal right now, as none of the other Rust Arrow libraries do. 2. Plan to release Rust ADBC library independently from other libraries, with its own (semantic) versioning. I think these two can be considered independently; if we find a strong reason to keep the Rust versions the same as other libraries, I'd still hope it would be fine to have the Rust API be experimental for some period. On Wed, Mar 1, 2023 at 8:12 PM Will Jones <will.jones...@gmail.com> wrote: > Hello Arrow devs, > > I have created a PR to define a Rust API for ADBC [1], meant to parallel > the ones in C, Go, and Java [2]. I'd like to get feedback on that. This API > will be considered part of the ADBC format. Once I have addressed all > feedback, we will put forward a vote for adoption into the ADBC standard. > > In the meantime, I will continue prototyping the Rust driver manager and > implementation module (for building C API drivers with Rust). [3] These > prototypes informed the proposed API design and will rely on this API. > Hopefully those will be ready for review shortly after we adopt the API > standard. > > Best, > > Will Jones > > [1] https://github.com/apache/arrow-adbc/pull/478 > [2] https://arrow.apache.org/adbc/0.2.0/format/specification.html > [3] https://github.com/apache/arrow-adbc/pull/446 >
