Discuss: Release object store `0.12.0` (breaking) or `0.11.2` (non breaking API) around Dec 15, 2024

[alamb]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Follow on to #59

object_store 0.11.1 was released Oct 20, 2024

Per release schedule here https://github.com/apache/arrow-rs/tree/master?tab=readme-ov-file#object_store-crate we aim for
2 months release

Describe the solution you'd like

• Update version + make release noted
• Prepare release candidate + begin vote thread
• Release to crates.io
• File tickets for next planned releases

Describe alternatives you've considered

1. Another incremental release
2. A major release including breaking API changes (e.g. to include object_store: Migrate from snafu to thiserror arrow-rs#6266)

Additional context
I don't have any preference, though I personally think apache/arrow-rs#6266 is a nice to have

[tustvold]

I agree that at the moment we probably don't have enough to justify a breaking release.

Some other things that might be breaking, but not sure if/when we will see anything in that space

• Support 32-bit Architectures / Replace usize with u64 arrow-rs#5351
• Use 'static lifetime in BoxFuture for all object-store APIs arrow-rs#6587
• Make LocalFileSystem an Optional Feature #62

[alamb]

I propose that we plan to make the next object_store release 0.11.2 (non breaking) and try to make it next week. Please let me know if you have ojections

[tustvold]

I'd like to propose we proceed as planned with a non-breaking release next week, and then do a breaking release late February in advance of the scheduled March breaking arrow release. There are some non-trivial new features / bug fixes that I am aware people are waiting on use releasing, and a breaking release would significantly delay getting these into the hands of users.

However, having the next release be breaking would allow us to start incorporating breaking changes into main in a week's time, once this release has been cut.

If there are major non-breaking features that land during that time, we can consider cutting another 0.11 patch release, presuming the contributor is willing to backport their changes.

[alamb]

I think @tustvold 's plan sounds good. Unless there objections I'll update the tickets to reflect that

[benesch]

Sounds great to me as well! Eager to be able to incorporate this into SlateDB.