Hi folks, The fix for https://github.com/apache/iceberg/issues/18191 has been merged. We are cutting a new RC for this release. I'll open a new thread for the voting on the new RC.
On Mon, Sep 21, 2026 at 5:05 AM Alex Dutra <[email protected]> wrote: > +1 (non-binding) > > I verified the following on macOS with JDK 21: > > - GPG signatures, checksums, git tag and version.txt all OK > - Source distribution builds successfully > - RAT license check OK > - LICENSE and NOTICE files look good > > Thanks, > Alex > > On Mon, Sep 21, 2026 at 5:57 AM Xin Huang via dev > <[email protected]> wrote: > > > > +1 (non-binding) > > > > Verified the RC on Linux with JDK 17: > > > > Source tarball GPG signature verifies against the official KEYS (Amogh > Jahagirdar) and the SHA-512 checksum matches. > > Tag apache-iceberg-1.12.0-rc0 points to > dec392570a88e45ac3a417a487dd72f9bdb629d5, and the tarball contents match > that commit (all 7,083 common files identical; only the two generated > version-info files differ, as expected). > > RAT license check passed (dev/check-license). > > Built from source with ./gradlew build: all tasks succeeded except two > iceberg-aws integration tests, which fail only because my machine has EC2 > instance metadata credentials; both pass with > AWS_EC2_METADATA_DISABLED=true. Not an RC issue. > > Verified all 288 staged Maven artifacts in Nexus > (orgapacheiceberg-1283): GPG signatures all verify against KEYS, SHA-512 > checksums all match. > > > > > > Thanks > > Xin > > > > On Sun, Sep 20, 2026 at 3:28 PM Neelesh Salian <[email protected]> > wrote: > >> > >> Thanks for all the voting and checks. > >> > >> I've filed an issue to track the source archive bundling a few > third-party doc-site assets under site/docs/assets/: > https://github.com/apache/iceberg/issues/18191 > >> We can decide how to move forward. > >> > >> Separately, adding my own vote on this thread > >> > >> +1 (non-binding). > >> > >> Verified on macOS: > >> - Source: GPG signature good, SHA-512 matches, tarball matches the > signed tag, license-header (RAT) check passes, and it builds from source. > >> - Staged Nexus convenience binaries are present and signed. > >> - Spark smoke against all four staged Spark runtimes > (iceberg-spark-runtime-3.5_2.12, 3.5_2.13, 4.0_2.13, 4.1_2.13): CREATE / > INSERT / DELETE / SELECT return the expected results. > >> - Flink smoke against all four staged Flink runtimes > (iceberg-flink-runtime-1.20, 2.1, 2.2, 2.3): CREATE / INSERT / SELECT > return the expected results. > >> > >> > >> On Sun, Sep 20, 2026 at 9:02 AM Manu Zhang <[email protected]> > wrote: > >>> > >>> +1 (non-binding) > >>> > >>> Verified: > >>> - Signature and SHA-512 checksum OK; signing key present in the > project KEYS file > >>> - Source tarball matches tag apache-iceberg-1.12.0-rc0 > (dec392570a88e45ac3a417a487dd72f9bdb629d5) > >>> - RAT license check passed; no binaries in the source release > >>> - ./gradlew build succeeded (checkstyle + revapi included) > >>> - api/core/parquet test suites: 10,991 tests, 0 failures > >>> - Staged jars carry iceberg-build.properties pointing at the same > commit and tag > >>> > >>> Tested on macOS (aarch64), OpenJDK 21.0.1, Spark 4.2, Flink 2.3, Scala > 2.12. > >>> > >>> Thanks, > >>> Manu > >>> > >>> On Sun, Sep 20, 2026 at 11:20 PM Anoop Johnson <[email protected]> > wrote: > >>>> > >>>> +1 (non-binding) > >>>> > >>>> Verified the source RC from > https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.12.0-rc0 > >>>> > >>>> - SHA-512 checksum matches > >>>> - GPG signature is good (signed by Amogh Jahagirdar; key in the > published KEYS) > >>>> - Tag apache-iceberg-1.12.0-rc0 points at > dec392570a88e45ac3a417a487dd72f9bdb629d5 > >>>> - Source tarball is reproducible from the tag (git archive matches; > only the release-generated version.txt and iceberg-build.properties are > added) > >>>> - version.txt is 1.12.0 > >>>> - RAT (dev/check-license) passed, no missing headers > >>>> - All modules compile cleanly (Spark 3.4/3.5/4.0, Flink, Hive, > Kafka Connect) with checkstyle/errorprone clean > >>>> - iceberg-api (1287) and iceberg-core (8950) unit tests passed from > the tarball > >>>> > >>>> Tested with JDK 17 on macOS. > >>>> > >>>> Thanks, > >>>> Anoop > >>>> > >>>> On Sat, Sep 19, 2026 at 5:13 PM huaxin gao <[email protected]> > wrote: > >>>>> > >>>>> +1 (non-binding) > >>>>> > >>>>> Verified the source RC from > https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.12.0-rc0 > >>>>> > >>>>> - SHA-512 matches > >>>>> - GPG signature is good > >>>>> - Tag apache-iceberg-1.12.0-rc0 points at > dec392570a88e45ac3a417a487dd72f9bdb629d5 > >>>>> - version.txt is 1.12.0 > >>>>> - RAT (dev/check-license) passed > >>>>> - iceberg-api and iceberg-core unit tests passed from the tarball > >>>>> > >>>>> Spark 4.2 (Scala 2.13) compiled from the tarball. I also ran > iceberg-spark and iceberg-spark-extensions tests locally; a small number > failed with BindException on sparkDriver and a couple of 5s > snapshot-isolation timeouts. Those look like this environment, not an RC > issue. > >>>>> > >>>>> Thanks, > >>>>> Huaxin > >>>>> > >>>>> > >>>>> On Sat, Sep 19, 2026 at 3:06 PM huaxin gao <[email protected]> > wrote: > >>>>>> > >>>>>> I am fine with keeping the #16765 toString() change in 1.12 and > documenting it as a behavior change. > >>>>>> > >>>>>> Old metadata still loads: "geometry" and "geometry(OGC:CRS84)" > parse to the same type. Writing the long form is clearer and matches > Appendix C. > >>>>>> > >>>>>> As Szehon mentioned, this also helps the UDF work I am doing > (#15994). A definition-id is built from parameter type strings. If omitted > vs explicit default algorithm printed differently, two equal Geography > types would look like two different overloads. With #16765 they print the > same, so we do not need a workaround for that case. > >>>>>> > >>>>>> Thanks, > >>>>>> Huaxin > >>>>>> > >>>>>> On Fri, Sep 18, 2026 at 8:22 PM Neelesh Salian < > [email protected]> wrote: > >>>>>>> > >>>>>>> Based on Szehon's comments, it makes sense to keep the behavior > change for 1.12. If we are making a change, I can make sure this is in the > Release Notes + Release blog so users are aware. > >>>>>>> At the end of the voting process for this RC thread here, we can > see where we land. > >>>>>>> Please vote on the RC when you get a chance. > >>>>>>> Thank you for all those who have voted thus far. > >>>>>>> > >>>>>>> On Fri, Sep 18, 2026 at 6:58 PM Anoop Johnson <[email protected]> > wrote: > >>>>>>>> > >>>>>>>> The API change behavior seems reasonable to me. If there are no > objections from the community, we should probably just keep it. If not, the > PR Xin prepared looks like a reasonable fallback. (thanks for turning that > around so quickly!) > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Anoop > >>>>>>>> > >>>>>>>> On Fri, Sep 18, 2026 at 6:06 PM Szehon Ho < > [email protected]> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Thanks for the thorough review! Indeed, toString() of the > Geometry/Geography type is changed to include crs, algorithm parameters, > even if they are the same as default. > >>>>>>>>> > >>>>>>>>> I took a look, for me it seems ok to keep the API behavior > change for 1.12, and put it in the "Behavior Change" category of the > release notes. Some reasons: > >>>>>>>>> > >>>>>>>>> 1. It's just clearer overall. We found without this change, two > Geography type having the same default algorithm print differently > depending on whether the user sets it or not, which seemed like a bug. > >>>>>>>>> 2. toString() now matches the serialization spec, which includes > C and A: > >>>>>>>>>> > >>>>>>>>>> geometry(<C>) and geography(<C>, <A>) > >>>>>>>>> > >>>>>>>>> 3. It makes Iceberg JSON schema writer obey the spec as is > (using toString), avoiding the workaround. > >>>>>>>>> 4. It makes the Iceberg UDF PR that Huaxin is working on easier: > https://github.com/apache/iceberg/pull/15994. A UDF overload has a > definition-id which includes the param type string, and we'd have to > workaround in that code as well, otherwise its a correctness issue if two > Geography types with the default algorithm have different definition-id > depending on whether the user set it explicitly. > >>>>>>>>> > >>>>>>>>> Happy to hear what others think though. > >>>>>>>>> Thanks, > >>>>>>>>> Szehon > >>>>>>>>> > >>>>>>>>> On Fri, Sep 18, 2026 at 2:56 PM Xin Huang via dev < > [email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Steven, > >>>>>>>>>> > >>>>>>>>>> Thanks for catching this and bringing it to the community’s > attention. > >>>>>>>>>> > >>>>>>>>>> The reason for the change in #16765 was to persist the resolved > CRS and algorithm explicitly in metadata, including when they match the > defaults. Changing toString() was a side effect that I didn’t recognize as > a behavior change at the time. > >>>>>>>>>> > >>>>>>>>>> I double-checked Appendix C, which lists geometry(<C>) and > geography(<C>, <A>) as the canonical serialized forms. The spec also > defines the meaning of omitted parameters, so existing metadata must > continue to be interpreted using those defaults. > >>>>>>>>>> > >>>>>>>>>> I see three options: > >>>>>>>>>> > >>>>>>>>>> Restore the pre-#16765 behavior. Both toString() and schema > JSON use compact forms for default instances, although these differ from > the canonical JSON forms listed in Appendix C. > >>>>>>>>>> Restore the old toString() output while serializing explicit > parameters. For the same constructor inputs, toString() produces the > pre-#16765 output, while schema JSON and Java serialization include the > resolved CRS and algorithm. I’ve opened PR #18169 with this approach. > >>>>>>>>>> Keep #16765 unchanged. Both toString() and serialization > include explicit parameters, retaining the behavior change in 1.12. > >>>>>>>>>> > >>>>>>>>>> My preference is option 2, but I’m happy to follow the > community’s preference. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Xin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, Sep 18, 2026 at 11:12 AM Steven Wu < > [email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I want to call out a behavior change in 1.12. > >>>>>>>>>>> > >>>>>>>>>>> PR #16765 changed GeometryType / GeographyType so toString() > always writes the resolved defaults instead of omitting them. > >>>>>>>>>>> > >>>>>>>>>>> Before: Default instances collapsed to the bare type name. > Geometry with no CRS printed geometry. Geography printed geography, > geography(crs), or geography(crs, algorithm) depending on what was stored > as unset. > >>>>>>>>>>> > >>>>>>>>>>> After: the constructor stores omitted CRS / algorithm as the > Iceberg defaults, and toString() always includes them: > >>>>>>>>>>> > >>>>>>>>>>> geometry → geometry(OGC:CRS84) > >>>>>>>>>>> geography → geography(OGC:CRS84, spherical) > >>>>>>>>>>> > >>>>>>>>>>> Implications > >>>>>>>>>>> > >>>>>>>>>>> Read path is backward compatible, as SchemaParser or > Types.fromTypeName can parse the type string to the same Type object > >>>>>>>>>>> Write path is not string stable. > >>>>>>>>>>> > >>>>>>>>>>> Question: Do we consider the type's `toString()` change a > breaking change? Personally, I am okay with 1.12 moving forward with the > changed behavior since read is compatible. But I wanted to bring this to > the community attention. > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Sep 18, 2026 at 9:57 AM Gianluca Graziadei < > [email protected]> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> +1 (non-binding) > >>>>>>>>>>>> > >>>>>>>>>>>> Verified checksums, signature, source archive vs. tag, RAT, > and ran > >>>>>>>>>>>> smoke tests with the staged Spark 4.0 runtime. > >>>>>>>>>>>> > >>>>>>>>>>>> One follow-up, in the same spirit as Xuanwo's note: the source > >>>>>>>>>>>> archive also bundles > site/docs/assets/javascript/lottie-player.js > >>>>>>>>>>>> (LottieFiles, MIT) without a license header or an entry in > the root > >>>>>>>>>>>> LICENSE. Not a blocker for this RC since both assets have > shipped > >>>>>>>>>>>> since 1.9.0; this issue is already tacked here > https://lists.apache.org/thread/hstl6z6qp55hxgdlljpc5xg8wc3kq800 > >>>>>>>>>>>> > >>>>>>>>>>>> Separately, while testing I hit a pre-existing > NoSuchMethodError when > >>>>>>>>>>>> reading variant columns with commons-lang3 < 3.13 on the > classpath > >>>>>>>>>>>> (iceberg-parquet uses Streams.of(Iterable) without declaring > the > >>>>>>>>>>>> dependency). Also present in 1.11.0, so not a regression; > issue tracked here > >>>>>>>>>>>> https://github.com/apache/iceberg/issues/18164 > >>>>>>>>>>>> > >>>>>>>>>>>> Cheers, > >>>>>>>>>>>> Gianluca > >>>>>>>>>>>> > >>>>>>>>>>>> On 2026/09/18 00:22:06 Neelesh Salian wrote: > >>>>>>>>>>>> > Hi Everyone, > >>>>>>>>>>>> > > >>>>>>>>>>>> > I propose that we release the following RC as the official > Apache Iceberg > >>>>>>>>>>>> > 1.12.0 release. > >>>>>>>>>>>> > > >>>>>>>>>>>> > The commit ID is dec392570a88e45ac3a417a487dd72f9bdb629d5 > >>>>>>>>>>>> > * This corresponds to the tag: apache-iceberg-1.12.0-rc0 > >>>>>>>>>>>> > * > https://github.com/apache/iceberg/commits/apache-iceberg-1.12.0-rc0 > >>>>>>>>>>>> > * > >>>>>>>>>>>> > > https://github.com/apache/iceberg/tree/dec392570a88e45ac3a417a487dd72f9bdb629d5 > >>>>>>>>>>>> > > >>>>>>>>>>>> > The release tarball, signature, and checksums are here: > >>>>>>>>>>>> > * > https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.12.0-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-1283/ > >>>>>>>>>>>> > > >>>>>>>>>>>> > Please download, verify, and test. > >>>>>>>>>>>> > > >>>>>>>>>>>> > Instructions for verifying a release can be found here: > >>>>>>>>>>>> > * > https://iceberg.apache.org/how-to-release/#how-to-verify-a-release > >>>>>>>>>>>> > > >>>>>>>>>>>> > As this vote spans the weekend, it will remain open until > Monday, September > >>>>>>>>>>>> > 21, 2026 at 2:00 PM Pacific Time. > >>>>>>>>>>>> > > >>>>>>>>>>>> > [ ] +1 Release this as Apache Iceberg 1.12.0 > >>>>>>>>>>>> > [ ] +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. > >>>>>>>>>>>> > >
