Because this crate depends on arrow-rs and exposes it in its public interface, and because arrow-rs is releasing major versions every few months, this crate should also release a new major version every time that arrow-rs is updated.
This is obviously not desired, so there are a few options:
don't bump major version of this crate when arrow-rs is updated: this would lead to breaking changes in minor releases of this crate, breaking semver guarantees every few months.
don't update arrow-rs at all, until they release a "long-term-support" version that is not meant to be the last major version. When such version of arrow-rs exists, this crate can release version 2.x.x.
copy the whole arrow-rs API into this crate and maintain a stable implementation here. This is probably not feasible.
In essence, the problem is that arrow-rs is not yet considered stable and should be on version 0.52.x, but is on 52.x.x for historic reasons. So it shouldn't be exposed from 1.x crates.
Because this crate depends on arrow-rs and exposes it in its public interface, and because arrow-rs is releasing major versions every few months, this crate should also release a new major version every time that arrow-rs is updated.
This is obviously not desired, so there are a few options:
In essence, the problem is that arrow-rs is not yet considered stable and should be on version 0.52.x, but is on 52.x.x for historic reasons. So it shouldn't be exposed from 1.x crates.
All of this is discussed here: https://github.com/apache/arrow-rs/issues/5368