Thanks Steven!
On Jul 3, 2025, at 1:56 PM, Steven Wu <stevenz...@gmail.com> wrote:
> because it makes a bit of backward incompatible change by using the Spark behavior (for argument case sensitivity and type coercion support), we should do it in 1.10 release as we will have Spark 4.0 as part of it iiuc. Else 1.11 will be backward incompatible for the Spark 4.0 jar. Szehon, thanks for bringing up PR 13106. I agree with your argument here. It will be great to include this in the 1.10.0 release to avoid a behavior change later because Spark 4.0 support was released in this version. It seems close as you already approved it. Can we get a couple more approvals?
Hi Steven
Its not a blocker but I feel, because it makes a bit of backward incompatible change by using the Spark behavior (for argument case sensitivity and type coercion support), we should do it in 1.10 release as we will have Spark 4.0 as part of it iiuc. Else 1.11 will be backward incompatible for the Spark 4.0 jar.
Thanks, Szehon
Szehon's backport PR has been merged. Another blocker (dangling DVs for rewrite) was also merged.
There are still 3 blockers left, as a new PR (also danglinge DV related) is identified as a blocker. * being actively reviewed and worked on.
*being actively reviewed and worked on.
* It causes the number overflow error for engines who have nano precision long literal. Engines have to find workarounds currently. Potential solutions are discussed in the PR. E.g. provide a public method to construct a TimestampNanoLiteral so that engines/clients can use it. * I think it is a non-blocker for the 1.10 release. Treating the long literal always as micro (current behavior) is not a correctness bug. It is an important issue to be fixed so that engines can support nano timestamp literal without going through the hoops.
Thanks, Steven Thanks Steven for driving the release.
During today's community sync meeting, there are 2 PRs that are flagged as potential blockers. I have pushed other PRs to the next 1.11.0 milestone. These 3 PRs are the only open items left in the 1.10.0 milestone.
* Need community's help on reviewing this PR. Does the current change solve the issue? * If this still requires more significant work, we may want to roll back the aws-sdk version (like we did for the 1.9.0 release)
* The overflow error can be confusing. Is there any metadata or correctness issue due to this bug? If not, we can consider it as a non-blocker.
* Very close. should be merged very soon
It is not saying that we can't get other changes in the 1.10.0 release. Just that these 3 PRs are considered potential blockers.
Thanks, Steven Hi
I'm updated the PR about multi-args transforms today, but not sure I
will have reviews before 1.10.0. Let's try as best effort for 1.10,
else we will include in 1.11.
Regards
JB
On Tue, Jul 1, 2025 at 6:42 PM Steven Wu <stevenz...@gmail.com> wrote:
>
> Hi,
>
> I plan to cut a release branch in the next 1 or 2 days.
>
> Waiting for this row lineage related PR (and its 3.4 backport afterwards)
> https://github.com/apache/iceberg/pull/13070
>
> Other items in the 1.10.0 milestone will probably have to be pushed to the next 1.11.0 release
> https://github.com/apache/iceberg/milestone/54
>
> Thanks,
> Steven
|
