"Largest ordinal" may not be sufficient as a version number

[mguaypaq]

The README says:

Schemas evolve over time, and cross-compatibility is ensured provided certain rules are obeyed:

    A field definition cannot be deleted.
    A field ordinal cannot be altered.
    A field type cannot be altered (this includes the default value -- more on that later).
    A field name can be altered, as long as the old field name is added as an alias.

If these rules are obeyed, the largest ordinal can be considered to be the version number of the struct.

but it's possible to have gaps in the list of field ordinals, and it's possible to add new fields in one of these gaps. This should definitely be considered a new version (if it's allowed), even though the largest ordinal doesn't change.

[postamar]

You're correct, in that in order to prevent this, you don't want to create gaps, much less fill them. The real issue is that the schema is stored in a file, and a file can contain only the current definition, not the history of past definitions... You could represent the history in the file, which would then be append-only (i.e. a changelog) but that makes for unreadable schema definitions, IMHO not worth the trouble.

Perhaps I'll add a currently missing rule to fix this: when adding a new field, the ordinal should be the largest ordinal + 1. Please let me know what you think. Apologies for the belated response.