+1 (binding) I’ve gone through the changes in detail and I’m confident that they are implementable and working.
- Reviewed and updated row lineage core implementation, readers/writers, and updates to Spark 3.5 - Validated the Variant encoding and shredding spec - Built readers/writers for core object models for unknown, timestamp(9) types - Implemented default values and updated read paths - Reviewed table encryption PRs On Mon, May 19, 2025 at 3:20 PM Ryan Blue <rdb...@gmail.com> wrote: > Hi everyone, > > With the follow-ups from the earlier discussion thread wrapped up, I’d > like to raise a vote to adopt the v3 spec changes > <https://github.com/apache/iceberg/blob/main/format/spec.md#version-3-extended-types-and-capabilities> > . > > *What is included?* > > - Default values for columns and fields > - New types: variant, geospatial, timestamp(9), and unknown > - Row lineage and change tracking using synthetic row IDs and > row-level last modified sequence number > - Improved position deletes using binary deletion vectors that are > synchronously maintained > - Table encryption key tracking > - Table metadata support for future multi-argument transforms > > *What does adopting these changes mean?* > > Adopting the changes signals that we (the community) intend to support the > current set of changes and will maintain forward-compatibility for v3 > tables that implement the v3 spec. After adopting the changes, future > breaking changes would go into v4. > > As with v2 adoption > <https://lists.apache.org/thread/ws2gg52d124p7bx9jgrn3kctrtfgtltp>, this > is needed to build support in downstream projects and other > implementations. Adoption doesn’t change the default table version, it > signals that there will be no further break changes in v3 and that we are > confident in supporting the v3 features. > > Huge thanks to everyone that has worked to get to this point with the v3 > changes! > > Please vote in the next 72 hours: > > [ ] +1 Adopt the v3 changes to the table spec > [ ] +0 > [ ] -1 Wait to close v3 changes because . . . > > Ryan >
