camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 12:30:09 GMT
I posted the basic ideas and goals  of the refactorings in the Camel 3.0 
roadmap and also started discussions on DEV. One of the first is:
http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html#a3218958

The problem is that I could not already discuss the solution at that 
time. The dependencies in camel core were so confusing that it took me a 
lot of steps till the last pieces of refactorings needed to make the API 
self contained fell in place.

So of course I could have done all that in my own branch but then we 
would have had zero discussions. That is just not the way Apache is 
supposed to work. Instead I did the work in the open with DEV 
discussions and Jira Tickets where everyone can take part. I also 
reacted to any concerns. Of course I do not always agree but I think I 
changed a lot of the refactorings based on your comments.

Christian


Am 26.09.2011 13:53, schrieb Claus Ibsen:
> On Mon, Sep 26, 2011 at 1:29 PM, Christian Schneider
> <chris@die-schneider.net>  wrote:
>> Am 26.09.2011 11:04, schrieb Claus Ibsen:
>>> See the survey we did where people comment that they want the API stable.
>>> http://camel.apache.org/camel-30-roadmap.html (link on top of this page) We
>>> have not recently put our a survey to ask for feedback in the community if
>>> they want bigger API changes in the 2.x, that will break backwards
>>> compatibility.
>> Do you really dsitill the community will out of a single comment from the
>> survey? I believe that there can be many people who want a stable API but
>> the only reference I found in the survey was one single comment.
>>
> The following five comments refer to keeping Camel stable: #16, #18,
> #50, #57, and #58
>
> When I go to conferences and talk with existing Camel users, they all
> say to keep Camel stable as is.
> Some users who was using Camel 2.0 in its early days, refers to the
> API changing a bit, and causing upgrades to become
> harder, longer and to cost more man power and in the end more $$$.
The question is what people consider as stability. The API stability is 
only a part of that.
 From my own experience the stability problems in Camel almost never 
came from API changes. They mostly came from
bugs. So since we have patch releases I am sure people will consider 
Camel to be much more stable.

Btw. even a changed attribute in the file component is an "API" change 
for the user as it is the API he uses to access the
file component. Disallowing such changes would stop the whole innovation 
though.

I know it is a tough challenge to combine innovation and stability. On 
the long run though a well designed API and camel core will be the
basis for a stable and flexible camel. Camel core has grown for much too 
long without a redesign. One example is all the wrapping that is done for
interceptors, debugging, tracing, transaction. I assume that this 
happened partly because of the focus on stability but also partly 
because it was just too much effort to do a redesign for just a new 
feature. The result of this is declining quality. At first it is not 
really visible but I think we either are at a point or will soon be 
where innvation will slow down because of all the design issues.

Christian


-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message