On Thu, 9 Jul 2026 at 01:29, Ryan Blue <[email protected]> wrote: > > Forward-compatible changes are documented in the spec, just like > forward-incompatible changes. The difference is that you don't have to > change the compatibility level of a file by increasing the format version > to write them.
Gotcha, that's helpful. So we're talking not about fixed versions, but rather about compatibility levels, which, importantly, are mutable. So compatibility level v1 from next year may differ from compatibility level v1 today (if additional non-breaking features were added in between). One consequence is that there's a bit of ambiguity about what it means to say "a reader is compatible with v1": while it must be able to parse such a file, it may or may not support all of the latest v1 features. One way to make this more explicit would be to bump the minor version (v1.0 -> v1.1) when making backwards compatible changes. A v1 reader would be able to read all v1.x files, but it may ignore parts of it (if "x" is newer than what it knows about). If that's the intent, I think it would be good to capture the complete model in a persistent form, perhaps CONTRIBUTING.md as was suggested elsewhere, or a separate doc focusing on the versioning scheme. That way, people know what they are voting on in the ongoing vote, and there's a reference to the model in the future which is easier to find than the ephemeral voting thread. Best, --Gunnar
