camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 12:36:27 GMT
Again, it seems to me that you're implying Claus has problems with the
changes you did.
Reading his emails, I think the problems are more related to which branch /
when do the changes rather than if we do the changes.

On Mon, Sep 26, 2011 at 14:30, Christian Schneider

> 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
>> <>  wrote:
>>> Am 26.09.2011 11:04, schrieb Claus Ibsen:
>>>> See the survey we did where people comment that they want the API
>>>> stable.
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
> Open Source Architect
> Talend Application Integration Division

Guillaume Nodet
Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message