State of Wayland protocol development

[Jonas Ådahl]

On Sat, Sep 19, 2015 at 10:35:19AM +0300, Giulio Camuffo wrote:
> 2015-09-19 4:24 GMT+03:00 Jonas Ådahl <jadahl at gmail.com>:
> > 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.
> 
> A suffix would also allow compatible changes, you just need to not
> bump the suffix unless the change you're doing is backward
> incompatible. The _N suffix would be the major version number, the
> normal interface version would be the minor number. You bump the major
> if you're breaking compatibility, otherwise you bump the minor.
> My understanding of your proposal was that apps would need to bind the
> global only if the version is exactly the same as the one it
> implements, so that instead would not allow backward compatible
> changes. Did i misunderstand?

Ah, so you meant to add major/minor versioning. I guess that could work,
but I wonder if its worth the effort. I think one generally should
consider an experimental protocol to be still experimental and not
something one can rely on, and I'm not sure I'd want to support multiple
versions of an experimental protocol implementations anyway; but sure, it
would work just fine. In the end I think whoever designs a protocol can
make the call whether it is worth the effort of having major/minor version
seperation, and doesn't even need to decide it up front, as the a client
probably wouldn't even parse the suffix; as long as the names are
different it doesn't matter much what the difference is.


Jonas