Lines Matching +full:existing +full:- +full:versions +full:- +full:check

20 - Use `table`, not `struct`, for structured data.
21   - `struct` cannot handle optional fields; changes to `struct` are typically
23 - When adding new fields, do not modify the ID of existing fields.
24   - The easiest way to do this is to add new fields to the bottom of a `table`.
25   - If it's important to reorder the declaration of fields for readability,
27     that preserve their original zero-based indices.
28 - Fields must never be removed; they can only be deprecated using the
30 - Semantics for existing fields must not change without carefully auditing older
31   versions of the code to understand the implications.
32 - Default values for fields must be very carefully managed.
33   - Ideally, the default value for a field will never change.
34   - If they do change, audit old and new code to understand the implications of
36   - Note that fields with unspecified defaults will default to the zero value of
38 - Ideally the types of fields must not change. If they do, ensure that they are
50 can more easily upgrade to new versions of the Flatbuffers tools/library.
52 If we are forced to make a FC/BC-breaking change, it may make sense to create a
53 new `.fbs` file with a different `file_identifier`, and adding higher-level
54 logic to check the file magic before parsing the binary file with one schema or