Hi Jochen, Daniel, Thanks both.
Jochen, you're right that this lands on neither 1.1 nor 1.2 core. The docs now say exactly that: the YAML guide and a new Groovy 7 section in COMPATIBILITY.md describe the resolver as the JSON schema, stricter than the YAML 1.2 core schema, and list the values that change. On custom type transformations, Jackson 3's YAML parser doesn't expose a hook for that. Paul tried passing SnakeYAML Engine's CoreSchema through the factory's load settings, and it made no difference. Where types matter, the typed parseAs/parseTextAs path is the stricter option: it rejects "off" for a boolean property instead of handing back a truthy string. On your cases: - GitLab CI: groovy-yaml doesn't resolve aliases or apply merge keys, before or after this change (GROOVY-12358). The guide's SnakeYAML recipe does both, so that's the route for CI files today. Includes and !reference are GitLab's own, so they'd need handling on top either way. - Simple config files written to the newer schemas: no change, apart from 0x1F, 017 and 1_000, and Null/True and the like, which the core schema would still type. - Agentic AI output: the strict resolution helps here, and typed parsing also rejects unknown properties. - Skill files with front matter: extracting the block and passing it to parseText works as before. We aren't taking on a YAML 1.1 parser. The SnakeYAML recipe is documentation only and adds no Groovy dependency. Daniel, thanks for reviewing. The migration notes you asked for are in #2949 now: a COMPATIBILITY.md section (b6d43bc) listing each break with who is affected and what to do, plus the breaking-changes list in the PR description. Cheers, Scott On 2026-10-28 16:10 UTC Daniel Sun wrote: > Hi Scott, Jochen, > > Thanks for raising this on the list rather than letting it land quietly with > the Jackson 3 move. > > I agree the breakage around unquoted YAML 1.1-style scalars > (`yes`/`no`/`on`/`off`, mixed-case booleans, `~`, octal/hex) needs to stay > explicit for Groovy 7. Documenting it as a breaking change, pinning it with a > test, and pointing at SnakeYAML for documents that still need the older > typing looks like the right packaging for the default Jackson-based path. > > Jochen's point about not really landing on YAML 1.2 core either is fair; we > should keep the release notes honest about what the resolver does and does > not do. I am fine shipping with the documented behaviour if the guide and > migration notes stay clear, and I am happy to review #2949 / GROOVY-12433 > with that in mind. > > Cheers, > Daniel Sun >
