State of Wayland protocol development

[Jonas Ådahl]

On Fri, Sep 18, 2015 at 07:12:10PM +0300, Giulio Camuffo wrote:
> 2015-09-18 17:44 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
> > On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:

<snip>

> >>
> >> What do you do when you do a backward-incompatible change to a protocol?
> >>
> >> - Rename the globals or the protocol file? This would make people think
> >>   twice about the change as it would incur lots of churn in the code.
> >>   The churn shouldn't be a problem for review, since we wouldn't review
> >>   experimental implementations carefully. But it's still churn.
> >
> > The way I've done it and also the way we did with pointer gestures is to
> > prefix all of the interfaces with an underscore, with a note in the
> > global interface's description describing the limitations and lack of
> > backward compatibility as well as future intentions. See here[0] for
> > exact wording.
> >
> > A protocol bump can be backward compatible "by accident" and it'd be up
> > to the protocol designer to decide whether she/he wants to state any
> > compatibility, but the main idea is that a client should only bind the
> > exact same version it implements, and a server should terminate a client
> > that tries to bind an incompatible version.
> 
> We could also add a "_N" suffix to the interface name, where N would
> be the version number. This way a client can easily check the version
> of the interface implemented and only bind the global name with the
> right version, and at the same time it allows to do backward
> compatible changes to the interface by increasing the normal interface
> version.
> Moreover, if a compositor feels like it, it can implement many
> different incompatible versions of the interface at the same time.
> When stable, the _N suffix would be removed.

The version number would already be easily checkable as it is part of
the advertisement. What it would stop, however, is the possibility to have
backward compatible revisions of an experimental protocol since every
revision would change the interface name. So I don't think "_N" suffix is
desirable, since I think its more important to support potential
backward compatibility of experimental interfaces than multiple
implemented incompatible versions.


Jonas