Bug 82126

wl_compositor gets v3 because wl_surface is v3.

The documentation says "When the version of an interface increases, so does the version of its parent", the children not affected by the change won't be bumped. If children version got bumped, then nearly the whole protocol would bump version just because a little change somewhere, which can be quite insane.

Ok that makes sense I guess.

So the rule is to implicitly always create an object with the latest available interface version defined in the xml? That's doable I guess, although it makes parsing the protocol a pita as you have to keep and update state over the entire protocol when parsing the xml tree. :(

(In reply to comment #1)
> wl_compositor gets v3 because wl_surface is v3.
> 
> The documentation says "When the version of an interface increases, so does
> the version of its parent", the children not affected by the change won't be
> bumped. If children version got bumped, then nearly the whole protocol would
> bump version just because a little change somewhere, which can be quite
> insane.

Not almost the whole protocol, just everything under a single global interface in the hierarchy, which should be a tree. The hierarchy is defined by what interface (factory, parent) can create objects of another interface (child).

All new protocols must have the hierarchy as a tree, but the core protocol has wl_callback, which can be created via more than one unrelated interfaces, and that is a problem we cannot fix.

But yeah, there would be some churn and room for human errors, if we required all interfaces in a hierarchy to bump version at the same time.

(In reply to comment #2)
> Ok that makes sense I guess.
> 
> So the rule is to implicitly always create an object with the latest
> available interface version defined in the xml? That's doable I guess,
> although it makes parsing the protocol a pita as you have to keep and update
> state over the entire protocol when parsing the xml tree. :(

I'm not sure I understand what you are saying.

At code generation time, you would need to scan the interface hierarchy of each interface up to the root (global), and use the root's version for inferring what version numbers are valid at runtime for any child interfaces.

Then in each interface, you can pretty much ignore the version defined in the XML, and just look at the 'since' attributes to get the valid version ranges for each message.

That is, if you even need any concept of a "maximum version". The 'since' attributes say, that this message is available in versions this and all greater ones.

So looks like the version declared in the heading of the interface in the XML is pretty useless except for validating the XML, and for globals.

Ok, I think I can work with the current situation :)