Hi Aihua Ok got it. Thanks. Yes I agree with you: it has to be fixed as it sounds like a regression not seen on 1.9.0.
Regards JB Le jeu. 22 mai 2025 à 02:00, Aihua Xu <aihu...@gmail.com> a écrit : > JB, this is actually not a full revert but just a small change to make the > client with 1.9.x library to work with the existing catalog server. The > server will upgrade to 1.9.x and then the client will upgrade in the > following release. I feel it's a regression which didn't catch in 1.9.0 and > make sense to fix in 1.9.1. > > Thanks Russell. Busy with oncall to miss today's sync. I guess we agree to > move forward to make this fix? > > > > On Wed, May 21, 2025 at 3:17 PM Russell Spitzer <russell.spit...@gmail.com> > wrote: > >> Closing this vote to get in the fix requested by Aihua. New RC incoming! >> >> On Wed, May 21, 2025 at 2:59 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> As it's not a "regression" (it was like this in 1.9.0 even if not >>> "seen"), I'm fine to continue with the 1.9.1 release. We probably need >>> to work on a better/complete fix. >>> >>> I'm not sure reverting this change would make sense either. I'm more >>> in favor of continuing the 1.9.1 vote. >>> >>> Regards >>> JB >>> >>> On Mon, May 19, 2025 at 6:25 PM Russell Spitzer >>> <russell.spit...@gmail.com> wrote: >>> > >>> > As a heads up, this change is already present in 1.9.0. We could hold >>> off on 1.9.1 until we have a change that reverts the behavior in 1.9.0. I >>> think that would be fine as long as we have a volunteer to work on it, I >>> would be interested in just releasing 1.9.1 and then doing a 1.9.2 unless >>> we are sure the fix/revert would be quick. >>> > >>> > On Mon, May 19, 2025 at 12:14 PM Ryan Blue <rdb...@gmail.com> wrote: >>> >> >>> >> I think we should address the problem that Aihua pointed out. Even if >>> we can technically say that we are following the spec, this is a behavior >>> change that is known to break with existing REST catalog services. I don't >>> think that we should release a version that is known to break with existing >>> services that were based on the previous Iceberg version. >>> >> >>> >> I suggest that we implement a fix to handle multiple snapshot IDs for >>> this release so that services can upgrade to 1.9 and then update clients in >>> the next release. >>> >> >>> >> On Mon, May 19, 2025 at 10:03 AM Amogh Jahagirdar <2am...@gmail.com> >>> wrote: >>> >>> >>> >>> Thanks Aihua and Ajantha who pointed this out, >>> >>> >>> >>> If I understand the issue correctly, I don't think I consider it as >>> an incompatible change. The REST protocol always allowed for clients to >>> remove snapshots in bulk, it's just that we had a limitation in the >>> reference implementation that the batch size is 1. I'm guessing the failure >>> that's being seen on the server side is the assertion that the bulk size is >>> 1 which is no longer the case from newer clients? >>> >>> >>> >>> So in this case, newer clients are trying to express deletions with >>> larger sizes and the server is unable to handle it due to the assertion in >>> the older implementation, not because the protocol changed. Though I can >>> see the grey area in that it either forces clients to not upgrade for Java >>> server implementations which haven't upgraded OR it server implementations >>> end up upgrading, but this still feels implementation specific and not tied >>> to the protocol compatibility. >>> >>> >>> >>> >>> >>> >>> >>> On Mon, May 19, 2025 at 10:29 AM Aihua Xu <aihu...@gmail.com> wrote: >>> >>>> >>> >>>> I have verified RC against Snowflake build. Everything works except >>> one issue introduced by https://github.com/apache/iceberg/pull/12670/ >>> : the client with 1.9.x can't work with the catalog server with old >>> library to remove the snapshots since the the client now will remove the >>> snapshots in bulk while the old server doesn't support. Let me know if it's >>> considered an incompatible change. Otherwise, it looks good to me. >>> >>>> >>> >>>> On Mon, May 19, 2025 at 4:58 AM Péter Váry < >>> peter.vary.apa...@gmail.com> wrote: >>> >>>>> >>> >>>>> +1 (binding) >>> >>>>> Verified signature, built, and run some tests >>> >>>>> >>> >>>>> Maximilian Michels <m...@apache.org> ezt írta (időpont: 2025. máj. >>> 19., H, 11:17): >>> >>>>>> >>> >>>>>> +1 (non-binding) >>> >>>>>> >>> >>>>>> 1. Verified the archive checksum and signature >>> >>>>>> 2. Extracted and inspected the source code for binaries >>> >>>>>> 3. Compiled and tested the source code >>> >>>>>> 4. Verified license files / headers >>> >>>>>> >>> >>>>>> -Max >>> >>>>>> >>> >>>>>> On Mon, May 19, 2025 at 6:52 AM Daniel Weeks <dwe...@apache.org> >>> wrote: >>> >>>>>> > >>> >>>>>> > +1 (binding) >>> >>>>>> > >>> >>>>>> > Verified sigs/sums/license/build/test >>> >>>>>> > >>> >>>>>> > Checked that the iceberg build version is correctly represented. >>> >>>>>> > >>> >>>>>> > Ran into the hadoop commit test timeouts, but succeeded on >>> re-attempt (I believe we have fixes upstream for this). >>> >>>>>> > >>> >>>>>> > -Dan >>> >>>>>> > >>> >>>>>> > On Sun, May 18, 2025 at 5:20 PM Steven Wu <stevenz...@gmail.com> >>> wrote: >>> >>>>>> >> >>> >>>>>> >> +1 (binding) >>> >>>>>> >> >>> >>>>>> >> Checked signature, checksum, and licenses. >>> >>>>>> >> >>> >>>>>> >> Also ran Flink 1.20 with SQL. >>> >>>>>> >> >>> >>>>>> >> Thanks Russel for driving the release! >>> >>>>>> >> >>> >>>>>> >> On Sun, May 18, 2025 at 2:27 PM huaxin gao < >>> huaxin.ga...@gmail.com> wrote: >>> >>>>>> >>> >>> >>>>>> >>> +1 (non-binding) >>> >>>>>> >>> Verified signature, checksum and license. Thanks Russell for >>> driving this release! >>> >>>>>> >>> >>> >>>>>> >>> Huaxin >>> >>>>>> >>> >>> >>>>>> >>> On Sun, May 18, 2025 at 2:03 PM Fokko Driesprong < >>> fo...@apache.org> wrote: >>> >>>>>> >>>> >>> >>>>>> >>>> +1 (binding) >>> >>>>>> >>>> >>> >>>>>> >>>> Checked signature, checksum, and licenses. >>> >>>>>> >>>> >>> >>>>>> >>>> Thanks Russell, for running this release! >>> >>>>>> >>>> >>> >>>>>> >>>> Kind regards, >>> >>>>>> >>>> Fokko >>> >>>>>> >>>> >>> >>>>>> >>>> Op zo 18 mei 2025 om 01:05 schreef Yuya Ebihara < >>> yuya.ebih...@starburstdata.com>: >>> >>>>>> >>>>> >>> >>>>>> >>>>> +1 (non-binding) >>> >>>>>> >>>>> >>> >>>>>> >>>>> Confirmed that Trino and Starburst CI are green. >>> >>>>>> >>>>> It runs tests against several catalogs, including HMS, >>> Glue, JDBC (PostgreSQL), REST (Polaris, Unity, S3 Tables, Tabular), Nessie, >>> and Snowflake. >>> >>>>>> >>>>> >>> >>>>>> >>>>> BR, >>> >>>>>> >>>>> Yuya >>> >>>>>> >>>>> >>> >>>>>> >>>>> On Sun, May 18, 2025 at 2:13 AM Kevin Liu < >>> kevinjq...@apache.org> wrote: >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> +1 (non-binding) >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> - Verified signature, checksum, license. >>> >>>>>> >>>>>> * Build + test passed using Java 17 on M1 >>> >>>>>> >>>>>> * Ran a few examples on Spark >>> >>>>>> >>>>>> * Ran pyiceberg integration tests ( >>> https://github.com/apache/iceberg-python/pull/2011) >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> Best, >>> >>>>>> >>>>>> Kevin Liu >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> On Sat, May 17, 2025 at 10:02 AM Jean-Baptiste Onofré < >>> j...@nanthrax.net> wrote: >>> >>>>>> >>>>>>> >>> >>>>>> >>>>>>> Sorry I meant +1 (non binding) >>> >>>>>> >>>>>>> >>> >>>>>> >>>>>>> Le sam. 17 mai 2025 à 08:10, Jean-Baptiste Onofré < >>> j...@nanthrax.net> a écrit : >>> >>>>>> >>>>>>>> >>> >>>>>> >>>>>>>> +0 (non binding) >>> >>>>>> >>>>>>>> >>> >>>>>> >>>>>>>> - Signature and checksum are good >>> >>>>>> >>>>>>>> - ASF header present in expected file >>> >>>>>> >>>>>>>> - No binary found in the source distribution >>> >>>>>> >>>>>>>> - Build is OK >>> >>>>>> >>>>>>>> - Tested with spark and flink, need some update on >>> Polaris >>> >>>>>> >>>>>>>> - The aws-bundle, azure-bundle, gcp-bundle, >>> kafka-connect-runtime >>> >>>>>> >>>>>>>> LICENSE should include content for MIT and BSD (inline >>> or dedicated >>> >>>>>> >>>>>>>> folder), also, in case of dual license, we should >>> "exclusively" select >>> >>>>>> >>>>>>>> one. I gonna fix that, as it's like this for a while (I >>> missed that >>> >>>>>> >>>>>>>> before), it can be fixed in next release. >>> >>>>>> >>>>>>>> >>> >>>>>> >>>>>>>> Regards >>> >>>>>> >>>>>>>> JB >>> >>>>>> >>>>>>>> >>> >>>>>> >>>>>>>> On Fri, May 16, 2025 at 11:32 PM Russell Spitzer >>> >>>>>> >>>>>>>> <russell.spit...@gmail.com> wrote: >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > Hi Y'all, >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > I propose that we release the following RC as the >>> official Apache Iceberg 1.9.1 release. >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > The commit ID is >>> 5541cf000084b9e139d8dd22db44db7f592c3a2d >>> >>>>>> >>>>>>>> > * This corresponds to the tag: apache-iceberg-1.9.1-rc0 >>> >>>>>> >>>>>>>> > * >>> https://github.com/apache/iceberg/commits/apache-iceberg-1.9.1-rc0 >>> >>>>>> >>>>>>>> > * >>> https://github.com/apache/iceberg/tree/5541cf000084b9e139d8dd22db44db7f592c3a2d >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > The release tarball, signature, and checksums are here: >>> >>>>>> >>>>>>>> > * >>> https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.9.1-rc0 >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > You can find the KEYS file here: >>> >>>>>> >>>>>>>> > * https://downloads.apache.org/iceberg/KEYS >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > Convenience binary artifacts are staged on Nexus. The >>> Maven repository URL is: >>> >>>>>> >>>>>>>> > * >>> https://repository.apache.org/content/repositories/orgapacheiceberg-1201/ >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > Please download, verify, and test. >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > Please vote in the next 72 hours. >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > [ ] +1 Release this as Apache Iceberg 1.9.1 >>> >>>>>> >>>>>>>> > [ ] +0 >>> >>>>>> >>>>>>>> > [ ] -1 Do not release this because... >>> >>>>>> >>>>>>>> > >>> >>>>>> >>>>>>>> > Only PMC members have binding votes, but other >>> community members are encouraged to cast >>> >>>>>> >>>>>>>> > non-binding votes. This vote will pass if there are 3 >>> binding +1 votes and more binding >>> >>>>>> >>>>>>>> > +1 votes than -1 votes. >>> >>>>>> >>>>>>>> > >>> >>
