As a heads up, this change <https://github.com/apache/iceberg/commit/06f667ada5a5b9edeaa20ae9269ff5de1721b91d> 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 >> <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L2858>, >> 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. >>>>> >>>>>>>> > >>>>> >>>>
