published data standards having version is so wrong.

now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all.

all this is so silly. we will stick with json and informal-ini forever one way or another.

It's not ideal, I agree, but it solves real problems for people, so there's that.

Many commonly-used standards today weren't created by a bunch of wise men in a room thinking how to bestow their wisdom upon the rest of us, they often originated in real-world applications, were refined over a period of time based pn real-world experience, and then became a standard.

TOML is the same. I hope it will become an RFC some day. We just need to fix a few outstanding issues first.

Most commonly used TOML parsers support 1.0; adding 1.1 support should be pretty easy as the changes aren't that large (I did it in the parser I maintain, and it's 10 lines of code or so that had to be changed, most of them quite trivial).

My opinion is that having a version is fine buy only if a version field is built into the spec.

Without that your config file is a boobytrap, with it everything is fine and your parsing libraries can even be backwards compatible.

Since it's impossible to design anything great in tech on first attempt, what is the road to improvement without versions?

(and mentioning version could be a requirement in a future version)

And if you have to version it, Kelvin versioning is more appropriate for standards.

How do you know which version you are using though?

You don't; you check the library or application's documentation.

TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is.

I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes.

[1]: https://news.ycombinator.com/item?id=36020654

> You don't

Great. Very obvious.

As much as it pains me to say so, this is probably fine for configuration languages so long as they’re backwards compatible. Eg toml is used by rust’s cargo tool. Cargo can just say “hey Cargo.toml is parsed in toml version 1.1 format”.

How does your IDE and linter learn that?

In fairness it's probably not too bad as long as everyone actually migrates to the newest version eventually... But that isn't guaranteed - look at YAML. Or even JSONC. VSCode has a hard-coded lists of which `.json` files are actually JSONC. Gross.

YAML is way more complex and JSONC is not JSON 1.1

The is great news, thank you for your work on this.