Yes, no and YAML version 1.2 support

[Polo2]

Hi 👋 ,

Many thanks for all the work here, I'm very glad to parse some YAML files without thinking to it.

Today I had to investigate about a bit more, since a user made us an unexpected feedback, especially for Norwegian 🇳🇴 people.
Let's take this yaml file about languages:

language:
  type: string
  enum: 
    - en
    - fr
    - no
    - it

After some parsing for OpenAPI documentation, generated description was:

Values are en, fr, false, it

Obviously, Norwegian language was translated as false.
Digging into this, I understood it was YAML normal behavior for version 1.1, and that it will be changed with YAML 1.2

Of course we've suggested a workaround, to adapt YAML file with 'no' instead of no.
But just for asking, do you plan to support this new YAML spec version?

[emiltin]

Curious about this too.

[sandstrom]

We've had this issue too.

I think it would be great if Psych would do one of the following:

1. Drop support for YAML 1.1 altogether
2. Switch default behavior to assume YAML 1.2, and only parse it as YAML 1.1 if an option is passed (opt-out for 1.2-only)
3. Support parsing as only YAML 1.2 via an option (opt-in in for 1.2-only).

Among these, I'd prefer 2, but 3 would probably make more sense (and move to 2 in a future major version).

The boolean yes/no parsing, which I think is the only breaking change between YAML 1.1 and 1.2 is a common source of frustration, and the "feature" is rarely used deliberately.

[perlpunk]

There are much more breaking changes than just yes/no, have a look here for all the schema differences: https://perlpunk.github.io/yaml-test-schema/schemas.html

There are also syntax changes, some of them breaking, but rarely used.
For a (hopefully pretty much) complete list, see https://yaml.org/spec/1.2.2/ext/changes/

[sandstrom]

@perlpunk Good points! Much more than I thought, I've updated my comment. Thanks!

[forthrin]

+1. Any roadmap/ETA on this?

(Personally only concerned with not having to quote 'yes', 'no', 'on' and 'off', though obviously it's either 1.1 or 1.2!)

[Diti]

GitLab runner fails with otherwise perfectly valid YAML files because of this library using an obsolete version. Will it ever get updated? It’s been 17 years since the release of YAML 1.2.

You might consider switching to libfyaml.

[forthrin]

libfyaml presents itself as both a YAML and JSON library. Does it outperform the current (very fast) Ruby JSON library? If so, should both gems be updated, if footprint, maturity, safety and stability are prime?

Should maintainers for respective gems be consulted?

[andyw8]

Related: https://kddnewton.com/2025/12/25/psych-pure.html

a pure-Ruby implementation of a YAML 1.2 parser and emitter

https://github.com/kddnewton/psych-pure

[headius]

FWIW, JRuby's version of the psych gem has been using a YAML 1.2 backend for a few years (SnakeYAML-Engine), so this is only an issue for the libyaml-based extension.

[forthrin]

If psych-pure is the future and works for most but edge cases, it would seem yaml should be renamed yaml-legacy and psych-pure renamed yaml, with the usual deprecation warnings ahead and everything.

[forthrin]

PS! Taking a step back, YAML may feel like something of a miss, since it's disproportionately complex compared to its use (human-readable and easily editable configuration or data files). JSON, with all its noisy and intuitively redundant double-quotes, is ironically much faster to parse. TOML is yet more verbose once you want tree data. But guess we just have to work with what we have and not fall prey to the trap of inventing yet another yet another.

{
  "JSON": "(LL(1) / recursive-descent — deterministic one-token lookahead)",
  "users": [
    {
      "id": 1,
      "name": "A"
    },
    {
      "id": 2,
      "name": "B"
    }
  ],
  "flag": true
}

# YAML (context-sensitive; indentation-based — not LL(1); parsed with block/flow state machines)
users:
  - id: 1
    name: A
  - id: 2
    name: B
flag: true

# TOML (mostly LL(1)-friendly for key/value/arrays; tables introduce stateful sections)
[[users]]
id = 1
name = "A"

[[users]]
id = 2
name = "B"

flag = true

[headius]

I don't think the performance of the pure-Ruby yaml backend is where it needs to be yet, but perhaps some day. There's also benefits from using established libraries that have been verified and optimized for years.