discussion: Time-Based Release Schedule

[Xuanwo]

Hello, everyone. I'm starting this thread to discuss whether it's possible for us to implement a Time-Based Release Schedule, as demonstrated by @alamb in arrow-rs (see, for example, apache/arrow-rs#7395).

Having a predictable release schedule would allow iceberg-rust developers to deliver improvements and fixes on time. We hope users will be able to rely on tagged versions of iceberg-rust, rather than specific git commits, which will also be quite useful for debugging and discussions.

My current proposal is that:

iceberg-rust will release a new minor 0.x version every month, with additional patch 0.x.y versions as needed.

This means:

• iceberg-rust will actively evolve its public API, but we will make effort to minimize changes and provide clear deprecation notices and upgrade documentation.
• iceberg-rust will no longer use feature-based milestones. Instead, it will adopt a train model, with releases scheduled every month.

How can we do that:

• After releasing version 0.5.0, we will create a new tracking issue for release 0.6.0, specifying a clear deadline such as 2025-06-15. This issue will be used to track all blockers that could impact our next release.
• Once the deadline is reached, we will begin the release process. All blocker issues should be resolved by then; otherwise, they will be moved to the following release.

---

This proposal will only apply to iceberg-rust until it reaches v1.0, at which point we believe iceberg-rust will be mature enough for us to focus more on API stability and durability.

---

What do you think?

[Xuanwo]

Our existing releases:

• 0.2 at Feb 20, 2024
• 0.3 at Aug 19, 2024
• 0.4 at Dec 24, 2024

[ZENOTME]

Thanks @Xuanwo! Time-Based Release Schedule looks good to me to speed up the iceberg-rust evolution.

[alamb]

FWIW the challenges we could with monthly releases in arrow-rs is that it meant there were potentially breaking API changes every month for every release. Once the library was more stable and full featured, we now do releases with breaking changes every 3 months and releases without breaking changes in the months in between

[kevinjqliu]

+1, having a regular schedule should also help with adoption. Its particularly useful for the python binding, pyiceberg_core

Ideally, we'd want to make releasing as seamless as possible. I'll be the release manager for 0.5.0 and will be using the experience to improve the process wherever possible :)

[liurenjie1024]

I'm +1 for this proposal as iceberg-rust is under heavy development and moving fast, it's hard to avoid api breaking change. One suggestion is to have this discussion on dev list so that we could have more eyes on it.