Protocol backwards compatibility requirements?

Peter Hutterer peter.hutterer at
Sun Apr 12 23:59:01 UTC 2020

Hi all,

This is request for comments on the exact requirements for protocol
backwards compatibility for clients binding to new versions of an interface.
Reason for this are the high-resolution wheel scrolling patches:

Specifically, the question is: do we **change** protocol elements or
behaviour as the interface versions increase? A few random examples:
- event introduced in version N sends a wl_fixed in
  surface coordinates. version N+1 changes this to a normalized
  [-10000, +10000] range.
- request introduced in version N takes an int. version N+1
  changes to take a wl_fixed and an enum.
- request introduced in version N guaranteed to generate a single
  event wl_foo.baz. if the client binds to version N+1 that event may be
  sent zero, one or multiple times.

I think these examples cover a wide-enough range of the possible changes.

My assumption was that we only ever add new requests/events but never change
existing behaviour. So introduced in version N will always have
the same behaviour for any interface N+m.

I've seen some pushback for above linked patchset because it gets
complicated and suggestions to just change the current interface.
The obvious advantage is being able to clean up any mess in the protocol.

The disadvantages are the breakage of backwards compatibility with older
versions. You're effectively forcing every compositor/client to change the
code based on the version number, even where it's not actually needed. Or,
IOW, a client may want a new feature in N+2 but now needs to implement all
changes from N+1 since they may change the behaviour significantly.

So... what's our official stance on protocol backwards compatibility
requirements for clients binding to new versions? The last bit is important,
this is not a discussion about an changing existing version, merely about
future ones and binding to newer versions is opt-in for both compositor
and client.


More information about the wayland-devel mailing list