08:55 <pq> bl4ckb0ne, in a Wayland, because object version is usually inherited from the parent/factory object, bumping a child interface version *requires* bumping also the parent/factory interface version.

08:55 <pq> bl4ckb0ne, we just don't bother documenting all child interface *also* in all parent interfaces. :-)

08:56 <pq> bl4ckb0ne, so, you see what requests wl_compositor has, you see what new object types it can create, so you know where to look for version changes.

08:57 <pq> bl4ckb0ne, your code needs to explicitly handle all interface versions between 1 and the maximum version you support.

08:58 <pq> There is always the possibility that the the program on the other side of the connection will do only some lower version.

09:00 <pq> libwayland does automatically only very basic version checks: does this message exist or not. Everything else is up to you.

09:04 <pq> automatic wayland doc generators could collect a rough summary about version bumps to a global interface: which messages were added in which version of which child interface. The problem with that is that that may not be all the changes. Not all changes are machine-detectable, some are only spec wording.

09:04 <pq> parsing git history could work, though

10:59 <wlb> weston/main: Derek Foreman * input: Don't test uninitialized variables https://gitlab.freedesktop.org/wayland/weston/commit/9b7402ece91b libweston/input.c

10:59 <wlb> weston/main: Derek Foreman * input: fix surface jump test https://gitlab.freedesktop.org/wayland/weston/commit/bbd707d9bc3b libweston/input.c

10:59 <wlb> weston/main: Derek Foreman * data-device: Fix coordinate conversion https://gitlab.freedesktop.org/wayland/weston/commit/d3b74daabd8f libweston/data-device.c

10:59 <wlb> weston Merge request !1055 merged \o/ (input: Don't test uninitialized variables https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1055)

16:07 <bl4ckb0ne> pq: thanks for the clarification

16:08 <bl4ckb0ne> i guess binding v5 or v1 for the wl_compositor doesnt matter that much, im tempted to just use what `version` gives

16:11 <emersion> noooooooo

16:11 <emersion> never do this

16:11 <emersion> if we upgrade wl_compositor to v6, and add a new event to any of the child objects, then your client crashes

16:12 <emersion> has happened with wl_output :(

16:12 <emersion> and multiple broken clients

16:12 <bl4ckb0ne> yeah i remember the tidal wave of sway issue from chromium users

16:12 <MrCooper> this kind of mistake was a classic with X11 as well :/

17:16 <kennylevinsen> bl4ckb0ne: I usually always pick the current version at the time of writing the client

17:18 <kennylevinsen> It's just a way to avoid being broken by future changes to the protocol before you've had time to account for them, not something where you should pick a "right" version.

17:51 <dottedmag> emersion: I'm sorry, I'm not sure what is the exact situation. Client sending the version from the global, and being unable to handle new events?

17:52 <emersion> dottedmag: yes

17:52 <dottedmag> thnx