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 compatible
for one(or more) release(s)
3. Make the changes and damn the consequences
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 features
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 backward
compatibility maintained for a single release is probably the best option,
but option 3 would be more convenient.
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 the
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
to have a very stable API, methods should be renamed and planned features
added beforehand. If 1.0 is just another version, then this stuff doesn'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 tested.
The window manager is already obviously usable so I think somewhere along
the line it probably already should have been called 1.0. It almost seems
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:
- 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
The other major thing I think needs decided is what do we do with all of
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 this
to some sort of contrib section eventually, which we don't have yet. But
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 effective.
Some of the modules need to be refactored as well. There are a lot of
modules with circular dependencies, largely because utility routines crept
into their functionality that somebody else wanted. I'm not sure how to
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.
What does everyone else think?
- Scott
|
