Hi Jürgen,
> But it means also that components may not work with future versions
> and we have to rethink our compatibility paradigm.
That's the fault of the component using unpublished API ;)
Well, that's halfway serious only. Today, you cannot really blame the
component author since we have a lot of really useful unpublished API.
Not using doesn't make writing components more fun at all.
However, if we'd would produce better-quality API from the beginning,
and thus were able to publish it early, this problem could be minimized.
> I would agree that we still have some missing functionality here.
> But with ~700 unpublished API's you can get the impression that we use
> unpublished API's to be flexible for the future.
Well, my personal opinion is that as long as we don't have an
established API review process - which helps us defining mature API
before it's released into a product -, not publishing it is the only way
to prevent the mistakes we did in the past. Not optimal, sure. But
better than all those XSomeInterface7, which we would otherwise get
within a few years.
Of course, reviewing unpublished [1] API whether they can be published
should happen from time to time, and we have a deficiency here, too.
> It show me more that we have to be
> more careful with API's, i think we have to include API's in the spec
> process and we really need complete tests, examples and documentation
> before the API's get released. Writing tests, examples and documentation
> often shows potential specification errors and at this time we have the
> chance to change it.
+1
> Furthermore i would say that the API's are more important than the UI.
> But don't misunderstand me the UI has to be clear, intuitive and easy
> ... But when we find a problem in the UI we can easy change or correct
> it with the next release and probably no user has a problem with this
> change. But changing API's we can break potential extensions o customer
> applications using the API and that is more critical from my point of view.
+1, too. That's hard to sell to people designing the features, and to
people approving resources, but I think you're right here.
Unfortunately, the API definition process as done by a lot of people
(explicitly including myself here) doesn't really reflect this.
Ciao
Frank
[1] side note: I consider "published" a really really unfortunate term.
Published has a defined semantics of "it has been made publicly
available", but we use it as "it has been declared to be stable".
Probably, there's no chance to change this term, is it? :-\
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
