[jorams]

Your post's remark about YAML 1.2 being opt-in with a "%YAML 1.2" directive is true for the parser you are using (LibYAML), but is not compliant with the 1.2 spec. The spec specifies it should assume 1.2 and 1.1 should be opt-in.

[jmillikin]

It's true for all of the parsers that I tested at the time, which covered a couple different languages (Ruby, Python, C, Haskell).

It appears to still be true in at least Ruby and Python, which are probably the two most popular languages to write YAML-consuming programs in:

  $ irb -v
  irb 1.3.5 (2021-04-03)
  $ irb
  irb(main):001:0> require 'yaml'
  => true
  irb(main):002:0> YAML.load '{"a": 1e2}'
  => {"a"=>"1e2"}
  irb(main):003:0> 

and

  $ python3
  Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import yaml
  >>> yaml.safe_load('{"a": 1e2}')
  {'a': '1e2'}
  >>> 

--

  > The spec specifies it should assume 1.2 and 1.1 should be opt-in.

The spec for 1.2 says that, but that's the reason parsers can't upgrade to 1.2, because changing the default version will cause backwards-incompatible parsing changes. Without the version directive there's no way for the parser to know which version was intended, so it defaults to 1.1, so people writing YAML will write YAML 1.1 documents, because that's what the parsers expect.

The only way YAML 1.2 is going to displace older versions is in a greenfield ecosystem that has all its tools using YAML 1.2 from the beginning, but that requires an author who both (1) cares a lot about parser correctness, and (2) wants to use YAML as a config syntax, which isn't a large population.

[jorams]

It is indeed true for LibYAML, which is used by Python, Ruby, and the Haskell yaml package. The majority of YAML implementations I've seen that aren't based on LibYAML implement 1.2. I'm pointing it out because it's highly implementation dependent.