On Sat, 30 Oct 2010 09:03:47 +0200, Christopher Roy Bratusek wrote: > here's another proposal: Keep 1.7 as is, develop in 2.90. 1.8 will > the be counterpart of 2.90 but with 20% less suck > (say: all incompatible changes which would require the user to lay > hands on the configuration dropped).
Let's review factors one by one. First, main problems are stability of new feature and incompatibility which requires users to update their configuration, right? Now let's see examples. I'm going to send Timo's new `quote-event'. It'll be renamed to `deliver-next-input'. The old name func & command remain available, though I recommend users to update their settings. I also plan merging window list menus, old and beos. Current user config (require 'old-window-menu) will be replaced by something like (setq window-list-menu-style 'workspace), because it groups windows by workspaces, not by groups. They're ok for Sawfish-1.8. Do we agree on this? (Agh but the doc is tough. Wait a bit. ;) And do you agree that 1.8 will be released from the git master branch? On Sun, 24 Oct 2010 19:22:50 +0200, Christopher Roy Bratusek wrote: > the following is required to properly make sawfish 2.90 work > > - update sawfishrc for changed file-locations > - remove any reference to the old files from .sawfish/custom while > SawfishConfig is not > running (If you mean that Sawfish crashes with the old setting due to module renaming, then it can be avoided by adding define-structure-alias or provide, say in compat.jl. I don't think it's much bad.) (Except the above) I think edge will be stable enough. And with `edge-actions', EF users only have to add 4 lines to rc, and it doesn't require any lisp knowledge, so transition will be really easy. (`enable-viewport-drag' which assigns 4 border HS to ID will be nice. Then ID users have to write only 1 line in rc.) So I think it can go into 1.8. Inclusion of gtk+3 should bump the version for various reasons. About 2.90 *release*, without concrete examples, I can't say more. But we actually had incompatibilities in 1.6 and 1.7, so we don't have to worry too much now, I think. As for *git branch* "2.90", I'm against it, or at least you have to consider well before pushing. Isn't it much easier to use topic branches? The all-in-2.90 branch can be often unstable. There're many users who compile from git. (We notice it from complaints. :) For them, stable HEAD + stable topic branches are nice (news.texi and ChangeLog conflicts can be ignored.) For us developers, merge is much easier than pulling out ready-to-ship features to make a release(-candidate). And you have to keep track of which is done and which blocks. The list can grow really long. On the other hand, only (almost) finished features can go into 1.x git branch, so it's automatically, so to say, stable. It may be obvious, and a bit off topic, but our attitude is also asked to keep the quality. In fact, our last rename-window edit worsened the situation. Our discussion was not enough. I'll explain it later. Regards, Teika (Teika kazura)
