On Tue, 26 Aug 2014 10:36:58 +0100 Daniel Stone <[email protected]> wrote:
> Hi, > > On 23 August 2014 15:38, Pekka Paalanen <[email protected]> wrote: > > > On Fri, 22 Aug 2014 10:51:19 -0700 > > Jason Ekstrand <[email protected]> wrote: > > > On Fri, Aug 22, 2014 at 9:08 AM, Pekka Paalanen <[email protected]> > > 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
