First Release?

[BKLive]

I'm wondering if there is a plan to distribute a "stable" release of
euclid? At some point are all the required (or wanted) features going
to be implemented, and the code cleaned to the point of personal
satisfaction to make a non-snapshot version of euclid-wm. This way end-
users can update from the stable releases (v.1.1, etc) instead of just
for code cleanup or changing the way you implement a function without
changing the function for the end user. ie. if you clean up the code
for changing through views (or whatever), but the end user sees no
change on his end, just that it changes views as expected. This would
allow for a roadmap of desired updates/changes rather than just fixing
it on the fly. So essentially the releases would be based on the time
needed to implement x,y and z instead of when gotten around to it, and
make patching easier (for those who want it) because they could base
patches on releases instead of svn revisions.

Just a thought, wondering if there was a plan for this or not.

BKL

[William Diem]

There is, and I think the time for it is getting very close. My
original goal was to release a stable around rev 100, which is now
past us.

Here's what comes to mind now that I'd like to address before a release:

1) config files: I want to do away with the clunky install_conf make target.
What I want is to install the default configs into a system folder
(e.g., /usr/share/euclid-wm)
then have euclid check at startup whether the individual user has
config files in his home, if not, copy the system defaults into his
home folder. The questions:
Where should the defaults go? On Debian, I think they are put in
/usr/share/doc but I don't think this is used by other distros, like
Arch). Further, this system directory would be hardcoded somewhere, so
what if the user installs to a different dir?
The second question is whether this should be done by euclid-wm
itself, or by a startup script (e.g., go back to start-euclid). This
would be trivial, and frankly it is what I am leaning towards (the
only two disadvantages are the cost of starting a shell and the
potential to break some people's xinitrc). A benefit of putting it in
a script is that we can use sed to modify the start-euclid script at
install time to tell it where the default files are being installed.
2) I'm looking for thoughts on keybindings, are any turning out
awkward? Do testers tend to reassign certain ones in the config? For
me, the ; ' and , . / keys seems a little awkward. Not sure whether it
is just me or not. So before rolling a 1.0 I'd like to give myself a
little time to think over whether there is a better default (and
hopefully hear from some users). I don't really want to change the
defaults, but if it needs to be done I'd rather do it now (when the
userbase is small and expects things to change) than after a stable
release.
3) Check whether the conf file has all the options it should. Mainly a
matter of going through it and seeing what else can be easily added.
4) update documentation
5) resolve outstanding bugs (at the moment this is just the odd
behavior when a window in the stack crashes)
5) Little things I haven't thought of (I probably out to go back over
all the feedback and see whether there are things that got put off
that should still be done).

I guess I lot of what I'm doing right now is looking for ways that the
fundamental user experiance could be improved. I'm fairly happy with
the code itself at the moment. But this shouldn't really hold up the
release: The config is there, and as people use it i'm sure I'll get
more feedback on ways to improve it.

So once these things are done, I think think it will be time to
christen an rc. Then I'd like to give it about 5 days to a week to
test make sure there are no final bugs or regressions. Then tar-zip
and stick it out there.

Cheers,
Will