If you do version and size as the first two fields, you're basically there to backwards and forwards compatibility. Callers can request the size of the struct, allocate a buffer, and read out the parts they need. They can also check specific versions for what they support and ignore newer versions.

It also helps if you only append to the end of the struct for newer fields.

If you only access members, the version is not necessary. The receiver of the struct checks which members are present and ignores extra members that it does not know about. That's backward and forward compatibility.

The version could be useful if some members change their meaning across versions. But this would mean that you couldn't use a struct made from a future version because you wouldn't know about potentially changes.

Personally, I have only seen version or size, but not both. Do you have an example?

> It also helps if you only append to the end of the struct for newer fields.

This is actually required because changing or reordering existing members is an ABI break. Unless every version has its own dedicated struct. (This is often done in COM like APIs where interfaces are extended by adding a new interface. The client queries the must recent interface it knows about; if not supported, it tries the previous interface, and so on until it succeeds.)