Wayland and Weston 1.6 alpha snapshot (1.5.91)

[Pekka Paalanen]

On Tue, 26 Aug 2014 07:00:05 -0700
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Aug 26, 2014 4:32 AM, "Pekka Paalanen" <ppaalanen at gmail.com> wrote:
> >
> > On Tue, 26 Aug 2014 10:36:58 +0100
> > Daniel Stone <daniel at fooishbar.org> wrote:
> >
> > > Hi,
> > >
> > > On 23 August 2014 15:38, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >
> > > > On Fri, 22 Aug 2014 10:51:19 -0700
> > > > Jason Ekstrand <jason at jlekstrand.net> wrote:
> > > > > On Fri, Aug 22, 2014 at 9:08 AM, Pekka Paalanen <ppaalanen at gmail.com
> >
> > > > wrote:
> > > > > > Just before this alpha release, we bumped the xdg-shell
> experimental
> > > > > > version[1]. This means that the world breaks, as the experimental
> > > > > > version must be matched exactly. Jasper will be bumping Mutter
> and Gtk
> > > > > > to match. We expect to have another bump before 1.6.0 is out, but
> after
> > > > > > that I think it will be solid.
> > > > > >
> > > > > > Then, in 1.7.0 we plan to move the xdg-shell.xml file into
> Wayland, to
> > > > > > be installed as a stable protocol for everyone to use, and
> projects can
> > > > > > throw away their private copies of xdg-shell.xml. That would be
> the
> > > > > > point where xdg-shell starts to guarantee backwards
> compatibility. The
> > > > > > 1.7.0 release should be the last flag day for xdg-shell.
> > > > >
> > > > > One small note here.  Even if we don't make any changes to xdg_shell
> > > > > between 1.6 and 1.7, the universe will break again at 1.7.  This is
> > > > because
> > > > > we'll pull the experimental_version request which changes the order
> of
> > > > > things.  Do we have a plan for how to keep this from going too
> badly?
> > > >
> > > > Well, yeah, that is what I meant by a flag day, the world breaks,
> > > > but that should be the final one.
> > > >
> > > > Or do you think we should leave the experimental_version request
> > > > in, and just document it is no longer used, and make all code work
> > > > with it but ignore it? That would seem a bit strange to me.
> > > >
> > >
> > > How about the following as a happy compromise:
> > >   - bump the extension version from 1 to 2
> > >   - require set_experimental_version for clients binding v1
> > >   - assume an implicit experimental_version of 4 for clients binding v2,
> > > accepting but not requiring set_experimental_version == 4
> > >
> > > That avoids breaking existing clients regardless of which version they
> > > bind, but also means people hitting the new stable API don't have to
> bother
> > > with it. It would be nice if v1 was the stable API, and v0 was
> > > unstable/development, but alas the scanner won't let us do that ...
> >
> > That still means leaving the use_unstable_version request in the
> > protocol. This is the only time we could ever remove it.
> >
> > I think I would like more of the following, because for the 1.6 alpha,
> > we already broke the world:
> >
> > - During the 1.6 alpha phase, as changes land to xdg-shell, we bump the
> >   unstable version, breaking the world each time. This is a 2 week
> >   period already running.
> > - Just before 1.6-RC1 is about to be released, we remove the
> >   set_unstable_version request. This acts as the final break-the-world.
> > - 1.6.0 will be released with a stable xdg-shell protocol, but still in
> >   Weston repository.
> > - During the 1.7 development cycle, maybe towards the end, we move
> >   xdg-shell.xml from Weston to Wayland, unchanged.
> > - 1.7.0 will release with stable xdg-shell in Wayland.
> >
> > The good thing about this is that we do not leave the
> > set_unstable_version haunting us, everything that worked against 1.6.0
> > will continue to work against 1.7.0 and later, unless we find a serious
> > flaw in xdg-shell that warrants a final break-the-world before 1.7.0 is
> > out.
> 
> The problem is that we can't really break the world once we remove
> set_unstable_version, or can we...?  In theory, if we really needed to, we
> could make break-the-world changes and bump the interface version and then
> kill any client that attaches to anything other than the "stable" version.
> It'd be ugly, but it would work.

Something like that as the backup plan, but I'm *really* hoping we will
not need that. So up till RC1, we could break the world on a whim, but
after it we will need a really really good reason to do so, and I am
willing to enforce that.

Btw. wouldn't reshuffling the request opcodes so that call signatures
are guaranteed to change have a similar effect to bumping the unstable
version? That is, all runtime server/client mismatches would end up
with some protocol error.

> > It also means, that during the 1.7 development cycle, we must do our
> > best to keep xdg-shell stable. New features may land, but they need to
> > bump the interface versions properly, and be completely backwards
> > compatible.
> 
> I'm not sure how confident I am in our ability to keep xdg_shell stable in
> 1.7.  Not that Jasper's doing a bad job or anything and xdg_shell has been
> pretty stable for a while.  I'm just not sure if my confidence level is
> quite high enough for that.  I'll give the xdg_shell spec another read with
> Jasper's changes and think about it.

If you feel we should not do this stabilization yet, say so, and let's
consider an alternate plan. We have to draw the line at some point, and
that point will not contain all required desktop features, otherwise we
would never reach it.

Also I am eagerly waiting for the xdg-shell updates.

I have seen complaints that the current situation is quite painful for
distributions, as Weston, Mutter, and Gtk are each using some "random"
version of xdg-shell at some random git-sha1 revision, and making them
all match is hard, especially Weston vs. Gtk. Failing to properly bump
the unstable version on incompatible changes has not helped either,
but at least we can start doing that again.


Thanks,
pq