You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm happy to volunteer as release manager for 0.11.0. I also have an offer from @CTTY to support the steps that require committer privilege.
It would be great to verify that the release runs smoother with the improvements made from #2864, and release changes that have been merged since we cut 0.10.x in June. I'm not aware of any blockers right now. I'd like to understand if anyone has anything they feel should block the 0.11.x branch being cut - please comment if so!
Should we move off nightly as part of this release now that the version has been upgraded? While thinking about this Rust is currently on version 1.98, should we increase the MSRV beyond 1.95
Should we move off nightly as part of this release now that the version has been upgraded? While thinking about this Rust is currently on version 1.98, should we increase the MSRV beyond 1.95
Kurtis and I had a quick chat about this. I'm not sure what the motivation is for testing on nightly and personally I'd prefer we simplify by sticking to stable too. Kurtis will follow-up with a new dev@ list e-mail to gauge opinions, but I think this can be left in 0.12 scope.
Just waiting on the must have changes here before we move forward: #3034 (comment)
After that, I'll ask Shawn or another committer to cut the release branch and open the crate version bump and changelog PR against that as the base branch.
I also opened #3185 to change how we handle new crates. Our current "publish the new crate by hand after the workflow fails" instructions don't work anymore now that we publish with cargo publish --workspace. More details in the PR.
The short version: reserve the crate name on crates.io when the crate is added, not at release time. And add a PR CI check to enforce it.
For 0.11.0, someone with crates.io access needs to reserve iceberg-property-macro before RC2. After that the release publishes through the workflow like normal.
One of these two PRs might be good to get into 0.11 since @CTTY specifically requested them as followups to get into the 0.11 release: #3180#3145. #3145 has a review round, but no author response, #3180 I think has all of the feedback incorporated.
thrift pulled with parquet 58 has CVEs and prevents us from pulling in iceberg in my organization.
parquet 59 dropped it for their own parquet-thrift and works fine. Main would build ok for me if we had a 0.11 version.
Catching up here. We addressed both the CI license check (#3293) and getting rid of the dependencies TSV files (#3338).
Is the only remaining blocker for 0.11 the pyiceberg-core LICENSE and NOTICE? #3239
For the pyiceberg-core license attribution, I have two PRs remaining. One in draft (#3414) and another to follow - I will follow up to ensure that draft is ready soon, though it may not be until Thursday.
Once those are in, we backport the changes and press on with 0.11.0 RC3.
Regarding CVEs, I have not evaluated the impact there.
I would be inclined to continue the release of 0.11 and then immediately as a community we can discuss if we are ready to move forward with 0.12. Alternatively, I would not be against dropping 0.11 outright and cutting 0.12, which would bring in all changes since the start of September. (Small caveat - I'd really like to try and work on the capabilities module I've mentioned elsewhere before we cut 0.12)
Alternatively, I would not be against dropping 0.11 outright and cutting 0.12, which would bring in all changes since the start of September. (Small caveat - I'd really like to try and work on the capabilities module I've mentioned elsewhere before we cut 0.12)
can we "re-cut" the 0.11 branch? as in, can we just take the latest main as 0.11?
29. > Alternatively, I would not be against dropping 0.11 outright and cutting 0.12, which would bring in all changes since the start of September. (Small caveat - I'd really like to try and work on the capabilities module I've mentioned elsewhere before we cut 0.12)
can we "re-cut" the 0.11 branch? as in, can we just take the latest main as 0.11?
We can, I'm indifferent here.
I'm still inclined to complete 0.11 as is and we move fast with 0.12 but happy to hear if others would prefer otherwise. My reasoning here is that I would like to see more guardrails for the V3 implementation work. (I owe a PR here.)
for me the sooner 0.11 gets out the better, whatever format as long as there is no CVE. I am more interested to be able to use the crate than any new feature.
29. for me the sooner 0.11 gets out the better, whatever format as long as there is no CVE. I am more interested to be able to use the crate than any new feature.
To be clear, 0.11 was cut on 3rd September and will be on parquet 58.
Activity
dannycjones commentedon Aug 20, 2026
I've drafted changes to the release guide that I'd like to see exercised for the next release! #3037
dannycjones commentedon Aug 25, 2026
I'm happy to volunteer as release manager for 0.11.0. I also have an offer from @CTTY to support the steps that require committer privilege.
It would be great to verify that the release runs smoother with the improvements made from #2864, and release changes that have been merged since we cut
0.10.xin June. I'm not aware of any blockers right now. I'd like to understand if anyone has anything they feel should block the0.11.xbranch being cut - please comment if so!CTTY commentedon Aug 25, 2026
Thanks Danny! I'm leaning toward having a fast release without adding extra blockers.
DataFusion 55 has been released and we haven't released a Iceberg rust version with the stable DataFusion 54.1.
dannycjones commentedon Aug 27, 2026
Ahead of cutting the release branch...
Must haves:
Should have:
Nice to have:
Kurtiscwright commentedon Aug 31, 2026
Should we move off nightly as part of this release now that the version has been upgraded? While thinking about this Rust is currently on version 1.98, should we increase the MSRV beyond 1.95
dannycjones commentedon Sep 1, 2026
Kurtis and I had a quick chat about this. I'm not sure what the motivation is for testing on nightly and personally I'd prefer we simplify by sticking to stable too. Kurtis will follow-up with a new dev@ list e-mail to gauge opinions, but I think this can be left in 0.12 scope.
dannycjones commentedon Sep 2, 2026
Agreement on the mailing list is to start 0.11 release process: https://lists.apache.org/thread/qs3tmtsg122l4pfsc7vx6pg4ngtx961x
Just waiting on the must have changes here before we move forward: #3034 (comment)
After that, I'll ask Shawn or another committer to cut the release branch and open the crate version bump and changelog PR against that as the base branch.
CTTY commentedon Sep 3, 2026
I just created a new branch 0.11.x: https://github.com/apache/iceberg-rust/tree/0.11.x
kevinjqliu commentedon Sep 10, 2026
Found a blocking issue and replied on the vote thread.
Heres the proposed fix: #3184
If we end up cutting a new RC i think we should include #3174 as well
EDIT: Claude also suggest to include the pyo3 0.29 bump from main, which closes the two advisories currently ignored in the audit config.
kevinjqliu commentedon Sep 10, 2026
I also opened #3185 to change how we handle new crates. Our current "publish the new crate by hand after the workflow fails" instructions don't work anymore now that we publish with
cargo publish --workspace. More details in the PR.The short version: reserve the crate name on crates.io when the crate is added, not at release time. And add a PR CI check to enforce it.
For 0.11.0, someone with crates.io access needs to reserve
iceberg-property-macrobefore RC2. After that the release publishes through the workflow like normal.dannycjones commentedon Sep 10, 2026
Thanks @kevinjqliu, particularly for the process improvements - these are great.
I think next steps are:
dannycjones commentedon Sep 10, 2026
I will also backport these two:
mbutrovich commentedon Sep 10, 2026
One of these two PRs might be good to get into 0.11 since @CTTY specifically requested them as followups to get into the 0.11 release: #3180 #3145. #3145 has a review round, but no author response, #3180 I think has all of the feedback incorporated.
6 remaining items
dannycjones commentedon Sep 24, 2026
That's awesome, thanks Xander! Would you mind opening a backport to branch
0.11.xfor this fix?xanderbailey commentedon Sep 24, 2026
#3270 done
xanderbailey commentedon Sep 24, 2026
Ah we need this backport #3271 first I think
dannycjones commentedon Sep 28, 2026
Next steps:
Thanks for the patience
xanderbailey commentedon Sep 28, 2026
@dannycjones I think my two backports are blocked because of minio in CI. Let me see if I can put up a fix...
xanderbailey commentedon Sep 28, 2026
Have combined that fix into #3271
dannycjones commentedon Sep 29, 2026
The list keeps growing 😅 thanks for putting up a fix for that!
tafia commentedon Oct 12, 2026
thrift pulled with parquet 58 has CVEs and prevents us from pulling in iceberg in my organization.
parquet 59 dropped it for their own parquet-thrift and works fine. Main would build ok for me if we had a 0.11 version.
kevinjqliu commentedon Oct 13, 2026
Catching up here. We addressed both the CI license check (#3293) and getting rid of the dependencies TSV files (#3338).
Is the only remaining blocker for 0.11 the pyiceberg-core LICENSE and NOTICE? #3239
dannycjones commentedon Oct 13, 2026
Hey Kevin,
For the pyiceberg-core license attribution, I have two PRs remaining. One in draft (#3414) and another to follow - I will follow up to ensure that draft is ready soon, though it may not be until Thursday.
Once those are in, we backport the changes and press on with 0.11.0 RC3.
dannycjones commentedon Oct 13, 2026
Regarding CVEs, I have not evaluated the impact there.
I would be inclined to continue the release of 0.11 and then immediately as a community we can discuss if we are ready to move forward with 0.12. Alternatively, I would not be against dropping 0.11 outright and cutting 0.12, which would bring in all changes since the start of September. (Small caveat - I'd really like to try and work on the capabilities module I've mentioned elsewhere before we cut 0.12)
kevinjqliu commentedon Oct 14, 2026
can we "re-cut" the 0.11 branch? as in, can we just take the latest main as 0.11?
dannycjones commentedon Oct 15, 2026
We can, I'm indifferent here.
I'm still inclined to complete 0.11 as is and we move fast with 0.12 but happy to hear if others would prefer otherwise. My reasoning here is that I would like to see more guardrails for the V3 implementation work. (I owe a PR here.)
tafia commentedon Oct 16, 2026
for me the sooner 0.11 gets out the better, whatever format as long as there is no CVE. I am more interested to be able to use the crate than any new feature.
dannycjones commentedon Oct 16, 2026
To be clear, 0.11 was cut on 3rd September and will be on parquet 58.