Dependency on arrow is dictating release cycle of this crate

[aljazerzen]

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:

1. 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.
2. 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.
3. 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.

All of this is discussed here: https://github.com/apache/arrow-rs/issues/5368

[aljazerzen]

This broke my build again. Please don't publish minor versions which expose an updated arrow dependency.

I'll now pin my dependency on duckdb to a minor version.

[Maxxen]

Hello! Sorry about that. The problem is that this crate tries to follow the duckdb versioning, which isnt really semver, and has a much slower release cycle than we would like to e.g. push bugifxes and other features.

The plan is to come up with a separate semver respecting versioning scheme for this crate eventually, but wed like to take the oppoprtunity to make larger changes to the build system/crate layout at the same time.

[mlafeldt]

Thank you for raising this issue.

I think it's a good idea to be a bit more conservative in updating Arrow, i.e. only update it as part of major DuckDB releases, and on an as-needed basis.