Additional compatibility data about zserio HOT 1 OPEN

We will try to make the first implementation applying the following requirements:

1. Schema authors should not be forced to decide at the beginning which type is relevant for forward/backward compatibility.
2. Overhead (data and runtime) for clients which are fully compatible should be avoided.
3. Compatibility data should be the same for any older compatible version.

The following restrictions will be applied:

1. Field removal or type change is forbidden.
2. Only adding field/item at the end of structures, choices, unions, enumerations and bitmasks are allowed.
3. Enumerations which use whole range of underlying type cannot be extended.
4. Choices which have non-empty default case cannot be extended.

Our current solution will be storing the bit size of all compounds (encoded as varsize) in the independent data stream (called
compatibility data).

In the first implementation, compatibility data will be compressed using RLE (efficient for array of compounds of the same bit size). Further size optimizations could be possible in the future on demand.

Note: Don't forget to implement handling of bit size zero in compatibility data. Bit size zero means that compound type is not extended at all (was and is empty).

Note: Don't forget to properly document this feature.

from zserio.