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
<ch...@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
