Brendan Eich wrote:
>...
> 1. We intend to add target milestones through at least 0.9.7, and
> milestone keywords for nominations. As we've said often, we're not
> looking for new features; we want stability, performance, standards
> compliance, and good APIs.
I could rant about usability not being in that list, but I won't. I'll
just note that stability is *only* important because crashing is the
most extreme conflict between what the user expects to happen and what
actually happens. I'd argue that a build which crashed on average once a
month, but had an annoying bug in the text entry widget (a less severe,
but much more frequent, conflict between the user model and the system
model), would be of worse quality overall than a build which crashed
once a week but which didn't have the text entry bug.
>...
> Long story short: we need a schedule for the short term that
> culminates in a release with stable code and APIs (APIs broadly
> construed: XUL syntax is an API, as are XUL semantics; but not every
> C++ or XPCOM API will be public or frozen,
> see http://www.mozilla.org/projects/embedding/).
>...
Does this mean that the APIs will *only* be frozen on the 1.0 branch,
and that they can be merrily changed on the trunk as soon as that branch
is cut?
For example, the nsIPromptService API is pretty badly broken -- i.e.
it's near-impossible to create well-designed alerts with it, and
extremely easy to create really bad ones. (I've read the code -- these
are bugs in the API, not just bugs in its implementation.) nsIPrompt is
used all over the place, and I can't imagine anyone volunteering to
rewrite it (and the code which uses it) in the near future. If we reach
1.0 with that API in its current state, how long will it be required to
stay that way?
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
