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 #5351
• Use 'static lifetime in BoxFuture for all object-store APIs #6587
• Make LocalFileSystem an Optional Feature #6055

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

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.

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

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

I filed a PR to add documentation and two tickets to track the next two releases

• [object store] Add planned object_store release schedule to crate readme #6904
• Release object store 0.11.2 (non API breaking) Around Dec 15 2024 #6902
• Release object_store 0.12.0 (API breaking) Around Feb 30 2025 #6903

🔥 very excited to incorporate the new CAS feature into SlateDB. 😁