[skip-ci][NFC][ntuple] add schema evolution docs

[jblomer]

No description provided.

[pcanal]

Suggested change

	Note for classes that have been given a version number, users must increase the class version number whenever the persistent layout changes (members marked as transient do not participate in the persistent layout).

In addition there is a quirk that we currently also need to increase the version number of a derived class if the base class changes. It is a really annoying feature and we should 'fix' it and thus it may or may not be worth mentioned it here.

[pcanal]

What do you mean? The TClass will be confused and issue an error/warning message if there is 2 StreamerInfo with the same version number but different checksum.

In the subset of cases where the StreamerInfo for the class stored in RNTuple is not stored in the file, then the above might be true as then the RNTuple layout is then clearly known to be its own but having the same version number marked in the RNTuple and the in memory layout will make the use of rules 'harder'.

Note that this is distinct from the case where the class is not (user) versioned at all. In this case each schema layout is distinct and look up is based on the CheckSum value.

[pcanal]

This may or may not deserve as asterix. I am guess the bound check is based on the underlying type rather than on the list of 'valid'/'explicit' enums values.

[pcanal]

Does we (eventually) want a (possibly optional) bound check here?

[pcanal]

Should we add a mention of the cases with fixed length collections (both vs other fixed length collections and variable collections). For example are the following supported?:

In-memory type	Compatible on-disk types
int[8]	int[4]
std::vector<int>	int[4]
std::array<int,4>	int[4]

And vice et versa.

[pcanal]

Note: std::array -> variable-length collection is already mentioned (but not the reverse).

[pcanal]

Should this mention (as a preview of the text) below whether this include user types related via a renaming rule?

[pcanal]

std::list and std::deque are not explicitly listed, are they supported here? (If they are not actively disallowed then they will likely just 'work' via the 'User-defined collection' code path (i.e. they have a CollectionProxy)).

[pcanal]

This might deserve a note/comment/asterix hinting at the reason why other transformation can not be supported.

[pcanal]

(minor)

Suggested change

	For the exact syntax of customization rules, please refer to the ROOT manual.

[pcanal]

Should we mention that if the given type differs from the on file type, the source member will undergo schema evolution before being passed to the rule's function?

[pcanal]

A source member can be read them into any type compatible to its on-disk type

What is the (them) part refering to?