> Probably major versions should match between C++ and PyArrow, but I guess > we could have diverging minor and patch versions. Or at least patch > versions given that > a new minor version is usually cut for bug fixes too.
I believe even this would be difficult. Stable ABIs are very finicky in C++. If the public API surface changes in any way then it can lead to subtle bugs if pyarrow were to link against an older version. I also am not sure there is much advantage in trying to separate pyarrow from arrow-cpp since they are almost always changing in lockstep (e.g. any change to arrow-cpp enables functionality in pyarrow). I think we should maybe focus on a few more obvious cases. I think C#, JS, Java, and Go are the most obvious candidates to decouple. Even then, we should probably only separate these candidates if they have willing release managers. C/GLib, python, and ruby are all tightly coupled to C++ at the moment and should not be a first priority. I would have guessed that R is also in this list but Jacob reported in the original email that they are already somewhat decoupled? I don't know anything about swift or matlab. On Mon, Apr 8, 2024 at 6:23 AM Alessandro Molina <alessan...@voltrondata.com.invalid> wrote: > On Sun, Apr 7, 2024 at 3:06 PM Andrew Lamb <al...@influxdata.com> wrote: > > > > > We have had separate releases / votes for Arrow Rust (and Arrow > DataFusion) > > and it has served us quite well. The version schemes have diverged > > substantially from the monorepo (we are on version 51.0.0 in arrow-rs, > for > > example) and it doesn't seem to have caused any large confusion with > users > > > > > I think that versioning will require additional thinking for libraries like > PyArrow, Java etc... > For rust this is a non problem because there is no link to the C++ library, > > PyArrow instead is based on what the C++ library provides, > so there is a direct link between the features provided by C++ in a > specific version > and the features provided in PyArrow at a specific version. > > More or less PyArrow 20 should have the same bug fixes that C++ 20 has, > and diverging the two versions would lead to confusion easily. > Probably major versions should match between C++ and PyArrow, but I guess > we could have diverging minor and patch versions. Or at least patch > versions given that > a new minor version is usually cut for bug fixes too. >
