> How important do you think backward compatibility is in Scwm? There
> are a lot of changes that should be made to clean up the code base
> to enable easier addition of changes. A lot of these changes would
> result in backward compatibility issues. I see roughly three ways
> to handle this:
>
> 1. Don't make the changes
> 2. Make the changes in a way such that the changes are backwards compat=
ible
> for one(or more) release(s)
> 3. Make the changes and damn the consequences
>=20
> Option 1, leaves us with a difficult to understand, inconsistent, and
> large code base. I don't think this is tenable in the long term.
> Option 2 requires a bunch of extra work to keep things
> backwards compatible along with extra code to report deprecated feature=
s
> and offer new ways to do things. Option 3 is the easiest coding wise
> but the hardest from a user perspective. I think option 2 with backwar=
d
> compatibility maintained for a single release is probably the best opti=
on,
> but option 3 would be more convenient.
>=20
I'll say go for option 3. Documenting the things that where changed and t=
he=20
way things are done now. That way the code can be changed and the wm is s=
till=20
usable.
> The different directions the code can be taken need some high level
> decisions to be make on which way to take the code. I feel funny
> making these decisions since I haven't put nearly as much effort into
> the code as Greg has. Nonetheless, some decisions need to be made.
> Do we clean up the code before we release 1.0? What's our policy on
> version numbers? What's our policy on backwards compatibility?
> When are acceptable times to put in an event or decoration rewrite?
> Do these need to be post 1.0? What is expected of a 1.0 release?
> Working code? Most code working? No known bugs? Stable API? Should
> the poor method names be renamed? When? Maintaining backward
> compatibility? For how long? How should methods be named? I think th=
e
> most important issue here is what are the expectations for version 1.0?
> If 1.0 is to be very stable, new features shouldn't go in right before
> it and the code should be changed little before hand. If 1.0 is meant=20
> to have a very stable API, methods should be renamed and planned featur=
es
> added beforehand. If 1.0 is just another version, then this stuff does=
n't
> matter so much. We've sort of built up expectations of 1.0 a bit by
> having all of these 0.99.* releases, but there don't seem to be any
> concrete guidelines of what constitutes 1.0. I would be inclined to
> make 1.0 more like just another release with the major subsystems teste=
d.
> The window manager is already obviously usable so I think somewhere alo=
ng
> the line it probably already should have been called 1.0. It almost se=
ems
> like we are reserving 1.0 for when we feel it is "done", whatever that
> means. If 1.0 is just like another release, this implies:
>=20
> - no special requirements need to be met for the next release to be
> called 1.0
> - not everything needs to be tested before 1.0
> - not everything needs to be documented before 1.0
> - the documentation for 1.0 doesn't need to be fancy
>=20
> The other major thing I think needs decided is what do we do with all o=
f
> the crap in the scheme directory. Obviously, most of the stuff is
> valuable, but there is stuff there that does not need to be there and
> just adds a bunch of maintenance cost. I would like to move some of th=
is
> to some sort of contrib section eventually, which we don't have yet. B=
ut
> doing so means we have to decide what stays and what goes. Perhaps, we
> could start marking the useless stuff as deprecated and see if anyone
> complains.
> We need to have deprecated functions print out a warning to make this=20
> effective.
> Some of the modules need to be refactored as well. There are a lot of
> modules with circular dependencies, largely because utility routines cr=
ept
> into their functionality that somebody else wanted. I'm not sure how t=
o
> deprecate this stuff effectively. I think we need to start deprecating
> a fair amount of stuff to allow for refactoring and to keep the project=
from
> falling under its own weight.
>=20
> What does everyone else think?
There are a lot of questions you ask, and as I am someone who just trying=
to=20
make scwm it's default window manager, my opinion should not weight heavy=
=2E=20
Please go ahead, make the changes, do what has to be done. Before removin=
g or=20
changing some functionality, it could be documented and discused in the n=
g=20
and put in the the announce list.
As what to do with the 1.0 version, one way to look at it is to say, well=
all=20
the people who worked on it all those years should have brought out an 1.=
0=20
version (and deserve it). My guess is that they where striving for=20
perfection, and always found one missing feature that needed to get in.
What direction you choose. Just let's get started. And afcource I'm willi=
ng to=20
help in any way.
pieter;
|
