State of Wayland protocol development

[Giulio Camuffo]

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?

>
>
> Jonas