+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.
>>>>>>>>>>>> >

Reply via email to