[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] Re: Avoiding Bloat
|
Hi Krzysztof,
I'm afraid that I don't understand what you want to
say.
The concept of provisional API in Eclipse exists today. We
have provisional
API in releases -- For Debugging, for instance, some
provisional API to
support better customization of views has been committed in
Eclipse 3.2
API, but it'll be promoted to official finalized API only
once everybody
agrees that it's the right way to go.
The point to be clear about is, that provisional API will
always
live
in "internal" packages
[2]. Once the API promotes to public, existing
clients of the provisional
API need to be refactored to the new (non-
internal) namespace. This need for
refactoring might be one of the
reasons why some clients are reluctant to adopt provisional
API.
Perhaps we'll need to better educate clients here, that this kind
of
simple rename refactoring doesn't really hurt that much.
The only
thing that it truly requires, is that clients which adopt
provisional API
need to be developed along with upcoming Eclipse releases:
When
a release makes the API public, the client needs to be
updated at
the same time as Eclipse in order to support
it.
seems to be exactly what you are
requesting?
I
agree that we need more feedback on API while it is still
provisional,
do you
have any ideas for better soliciting such feedback?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
As it was said before there is a
huge conflict of interests between developers & adopters.
It is a common guideline, almost
requirement, to create new API only where there is at least one consumer. And
this is a big problem. A consumer does not have to be an expert in particular
area. His requirement may be just a part of bigger functionality, or some
not-necessary-adequate point of view. More over, he probably tries to solve
his problem, and does not care about quality of Eclipse solution (because
commiters do it). So, commiters analyze, code, test, analyze again, discuss,
create some more code, and...
...API is finished when there is no more time (This is a lesson learned
from API workshop on last EclipseCon).
What happens next? New adopters arrive. Adopters of stable releases,
which are believed to be well designed and stable (and they are indeed in most
cases). The real, big feedback appears, and API evolves, but due to strict
rules it is necessary to maintain binary & contract compatibility.
I believe this is a problem - that the
true feedback & adoption occurs after the API is frozen.
Yes, I agree with some previous posts: we
certainly need API evolution approach in longer than release cycle and more
feedback about provisional API.
I
think it would be good to allow provisional API in Eclipse releases and make
it stable if the changes during new cycle are small enough. Of course
this solution has certain disadvantages - some code will be unstable despite
it is public. At this point we could encourage/force adopters to give us
feedback,
It is for their good - the
more feedback they give the more chances some functionality will graduate to
API.
We could thing also about
automatic refactoring scripts or some refactoring tools that would support
upgrading to next release. Or just point to critical places in the code and
indicate what should be done.
--
Christopher Daniel
Technical
Support Engineer
Eclipse Support Center
IBM Software Group
