On Aug 26, 2014 4:32 AM, "Pekka Paalanen" <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > > On Tue, 26 Aug 2014 10:36:58 +0100 > Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote: > > > Hi, > > > > On 23 August 2014 15:38, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > > > > > On Fri, 22 Aug 2014 10:51:19 -0700 > > > Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > > > On Fri, Aug 22, 2014 at 9:08 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> > > > 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. > 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. --Jason