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 <ch...@die-schneider.net>wrote: > 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<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<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 > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
