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 >>> <http://urldefense.com/v3/__https://github.com/apache/iceberg/pull/16765__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZslwUNqdQ$> >>> 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 <https://iceberg.apache.org/spec/#schemas>, >>> 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: >>> >>> 1. Restore the pre-#16765 >>> >>> <http://urldefense.com/v3/__https://github.com/apache/iceberg/pull/16765__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZslwUNqdQ$> >>> behavior. >>> Both toString() and schema JSON use compact forms for default >>> instances, although these differ from the canonical JSON forms listed in >>> Appendix C. >>> 2. 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 >>> <https://github.com/apache/iceberg/pull/18169> with this approach. >>> 3. Keep #16765 >>> >>> <http://urldefense.com/v3/__https://github.com/apache/iceberg/pull/16765__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZslwUNqdQ$> >>> 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 >>>> <https://urldefense.com/v3/__https://github.com/apache/iceberg/pull/16765__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZslwUNqdQ$> >>>> 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 >>>>> <https://urldefense.com/v3/__https://lists.apache.org/thread/hstl6z6qp55hxgdlljpc5xg8wc3kq800__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZucd-8rlQ$> >>>>> >>>>> 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 >>>>> <https://urldefense.com/v3/__https://github.com/apache/iceberg/issues/18164__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZuvdhMbeg$> >>>>> >>>>> 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://urldefense.com/v3/__https://github.com/apache/iceberg/commits/apache-iceberg-1.12.0-rc0__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZtNy1-EQg$> >>>>> > * >>>>> > >>>>> https://github.com/apache/iceberg/tree/dec392570a88e45ac3a417a487dd72f9bdb629d5 >>>>> <https://urldefense.com/v3/__https://github.com/apache/iceberg/tree/dec392570a88e45ac3a417a487dd72f9bdb629d5__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZsZEbwiNw$> >>>>> > >>>>> > The release tarball, signature, and checksums are here: >>>>> > * >>>>> https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.12.0-rc0 >>>>> <https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/iceberg/apache-iceberg-1.12.0-rc0__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZstALTGmw$> >>>>> > >>>>> > You can find the KEYS file here: >>>>> > * https://downloads.apache.org/iceberg/KEYS >>>>> <https://urldefense.com/v3/__https://downloads.apache.org/iceberg/KEYS__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZsc5zcLsw$> >>>>> > >>>>> > Convenience binary artifacts are staged on Nexus. The Maven >>>>> repository URL >>>>> > is: >>>>> > * >>>>> https://repository.apache.org/content/repositories/orgapacheiceberg-1283/ >>>>> <https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapacheiceberg-1283/__;!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZsXi0VR9A$> >>>>> > >>>>> > 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 >>>>> <https://urldefense.com/v3/__https://iceberg.apache.org/how-to-release/*how-to-verify-a-release__;Iw!!LIr3w8kk_Xxm!tKhzW34uoygDezpDOWiLjy5JRZ97R3veb-YTd5dqkITpmgITiZxSurPnO4FkDvwQ20sDnl_lIPSBk-GmvZs5jtCNBQ$> >>>>> > >>>>> > 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. >>>>> > >>>>> >>>>
