Re: [README] Sawfish 2.90 branched

[Teika Kazura <teika lavabit com>]

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)