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

Reply via email to