I don't think we have the resources (or structure) to do a big overview
either.
One of my basic ideas to reduce the amount of work is to stop
distinguishing between the public API of packages and classes, the
public API of subsystems, and the public API provided to modules and
plug-ins (see chapter 4 of the Cookbook). As a consequence, subsystems
spread over several packages will have to be reorganized. As another
consequence we will actually start using the java visibility rules.
If I were convinced that we all agree on what the subsystems are, their
responsibilities, and where the boundaries lay, I would have stressed an
immediate big change to solve this. I am not. Persistence and Model are
the two best defined subsystems w.r.t. responsibility and boundaries.
This is because they are "new" ;-).
I hope that eventually we will be able to get the clarity for all
subsystems and that every developer is striving towards this goal.
/Linus
Tom Morris wrote:
[...]
> > I'll then review what is left to try and define a more stable API.
>
> That brings up a question that's been rattling around in the back of
my
> mind
> as a result of the API compatibility questions. Should we try to do a
> focused review of the entire public API and do one big update where we
> warn
> developers of potential incompatibilites? Or is it better to just
keep
> trying to chip away at the problem incrementally? I'm not sure we
have
> the
> resources to do a global review, but figured I'd ask the question.
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
