Figure out and document the versioning and release cadence for object_store

[alamb]

in #2030 we incorporated the object_store crate into the arrow-rs repository and under the governance of the Apache Arrow project.

Now we need to figure out:

• What should trigger a release of a object_store (on a schedule, when someone wants, etc?)
• What versioning scheme should we use (e.g. should it be independent from the arrow/parquet/parquet-flight versions?)
• File tickets / make release scripts to run the release process

[alamb]

Here is what I propose:

1. Make an initial object_store 0.4 release and run the vote process as normal
2. Based on experiences there we can figure out if we want to make any changes

Any thoughts?

[nevi-me]

I'd support an independent versioning scheme. I don't know if it'd be possible to include changes along with other releases, so maybe when necessary we could release it soon after arrow releases.

I haven't had a chance to look at the code, so if it's possible to include a range version it could help avoid having to release a new update that follows arrow if there are no breaking changes to the crate.

[alamb]

At the moment, there is no dependency between arrow/parquet and object_store -- I am not 100% sure what @tustvold 's plan is in this regard

[tustvold]

I am not 100% sure what @tustvold 's plan is in this regard

I would like to at some point provide object_store integration within arrow-rs and parquet, behind an optional feature flag, as particularly in the case of parquet it can be non-obvious how to integrate them. I would expect, however, that in such a case bumping the major version of object_store depended on by arrow/parquet would constitute a breaking change to those crates.

That being said:

• I don't expect object_store to receive breaking changes at the same rate as arrow-rs, etc...
• I don't see a compelling reason to couple the versions of crates in the repo together, especially not those that change less frequently, e.g. object_store_rs, arrow-flight, parquet_derive, etc... This feels like a release tooling limitation more than anything else
• If we can avoid bumping object_store_rs to major version > 1, that would be my preference
• I don't feel particularly strongly about any of this, the version of a crate is somewhat immaterial provided semver is being followed, in practice whether it is 0.5 of 200.0.3 means very little

[alamb]

I don't see a compelling reason to couple the versions of crates in the repo together, especially not those that change less frequently, e.g. object_store_rs, arrow-flight, parquet_derive, etc... This feels like a release tooling limitation more than anything else

It is partly tooling (really the voting process) but also that any new release of arrow / parquet requires a new release of arrow-flight (at least with how the versioning is done today). Maybe @nevi-me 's suggestion for version ranges could help 🤔

But really there is no way to allow an older parquet_derive to work with a new parquet that has breaking API changes without a version bump as well

[alamb]

Given the feedback so far on this ticket, my plan will be to do an independent release of object_store 0.4.0. I will likely do this early next week as my "release management" capacity for this week will b consumed by the arrow-rs release.

Tracking with #2261

[tustvold]

I think this can now be closed as completed, feel free to reopen if I'm mistaken

[alamb]

TLDR conclusion is "we will release on demand unless/until there is need for a more automated release cadence" 👍