+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
>>> <https://github.com/apache/iceberg/pull/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
>>> <https://github.com/apache/iceberg/pull/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
>>> <https://github.com/apache/iceberg/pull/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
>>>>>>> <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.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>

Reply via email to