Wayland and Weston 1.6 alpha snapshot (1.5.91)

[Pekka Paalanen]

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.

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.

Does that sound good to everyone?


Thanks,
pq