3 ms·
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
by bdudbdjsh 3y ago
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.
- eviks 3y agoSince 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)
- arp242 3y agoIt'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).
- Marazan 3y agoMy 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.
- ruuda 3y agoAnd if you have to version it, Kelvin versioning is more appropriate for standards.
- isitmadeofglass 3y ago[dead]