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
and is still provisional as of today. See slide 4 of the EclipseCon 2008
DD
<http://www.eclipsecon.org/2008/sub/attachments/Device_Debugging_Project
_Update.pdf>
presentation [1]
<http://www.eclipsecon.org/2008/sub/attachments/Device_Debugging_Project
_Update.pdf> for reference. There are even clients of the provisional
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
<http://wiki.eclipse.org/Provisional_API_Guidelines>
in "internal" packages [2]
<http://wiki.eclipse.org/Provisional_API_Guidelines> . 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.
Note that as per the Eclipse Guidelines, all packages need to be
exported [3] <http://wiki.eclipse.org/Export-Package> , internal or not,
so everybody can adopt them. This
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?
[1] EclipseCon 2008 Device Debugging (DD) Update
http://www.eclipsecon.org/2008/index.php?page=sub/&id=45
http://www.eclipsecon.org/2008/sub/attachments/Device_Debugging_Project_
Update.pdf
[2] http://wiki.eclipse.org/Provisional_API_Guidelines
[3] http://wiki.eclipse.org/Export-Package
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Krzysztof Daniel
Sent: Friday, October 17, 2008 4:10 PM
To: [email protected]
Subject: [eclipse-incubator-e4-dev] Re: Avoiding Bloat
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
