Maybe one way to solve those problems would be to start a 3.0 branch and experiment / allow more api changes there and keep trunk stable for some time, then later switch when 3.0 begins to have more focus.
On Mon, Sep 5, 2011 at 17:44, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian <hzbar...@gmail.com> wrote: >> Claus, >> >> How exactly did you get to figure out what the community wants "NO CHANGES" >> in the the API an via what process were you nominated to express that >> opinion? >> > > I guess writing all caps was a way of getting attention. > The phrase should possible have been: KEEP API CHANGES TO A MINIMUM! > > I am not "the spokesman" as we *all* get exposed to the community. > But here is a few points from my exposure. > > I have been around the Camel community for a long time. I work on > Camel every day for a long time. I have been around at conferences > giving talks on Camel and being in touch with many exiting Camel > users, and new users as well. Likewise I get in touch with other > communities who integrates or want to integrate with Camel. Likewise > commercial companies of all sort get in touch with me via my employeer > to discuss Camel etc. > > Likewise we have the long term history of the Camel project and how > things works the usual way. Back in the days when we did Camel 1.x to > 2.0 we did *not* change the API in 1.x, but crafted a new 2.0 API and > released milestone releases and whatnot. > Prior to this we discussed the key API changes we wanted to do for > 2.0, such as removing the specialized exchanges, and only keen one = > DefaultExchange. Likewise the removal of the FaultMessage, and so on. > > What I hear from people and vendors is that they love Camel when the > API in 2.x started to settle down from Camel 2.4 onwards. We had a few > bumpy releases in the earlier Camel 2.x lifetime. Some of this can be > expected in a new major release etc. > They do not expect this to happen again now that Camel 2.x has been > around for 2+ years, the API is settled down, and the project is very > successful and they can rely on the API being as is. > > >> The reality is that the API did change in every single minor release of >> Camel, and my understanding is that this is an effort to actually clean it >> up and make sure it does not happen anymore after 3.0. The changes put on >> now are the painless ones that could be done before that. Afaik, you >> provided some useful feedback for some of these changes. >> > > Yes some changes in the API is okay. For example if there is issues > reported by the community. Or that we can archive major wins such as > better performance, reduced memory footprint and whatnot. Also API > changes in the DSL may be more tolerable, as the DSL is very end user > targeted, and end users would often recompile the Camel apps with the > new Camel version. Where as changes in component API is harder, as end > users may very well use 3rd party components which they dont recompile > or maintain themselves. Or the component maintainers dont want to keep > maintaing their components because Camel API changes every time. > Also we have other open source projects which integrates with Camel > and rely on API being stable etc. If we keep changing it, we just > loose those other open source projects, as they can't always spend > time and energy to keep up with Camel API changes. > > > Also Christian just started this "out of the blue" without any > consensus from the Camel team, prior discussions, request from the > community, as well the timing was a bit off, as he started during the > summer holiday. > > I am sure the internal API refactorings is nice. But every time you > change something you risk introducing new bugs. In fact he did, which > some I was able to point out. However we have a lot of unit tests > which often help pickup against regressions. But there is always a > risk. > > So if Christian could keep his toes to internal low risk refactorings > that would be nice. > The community would appreciate that the 2.x API is stable. > > Then I would suggest Christian started a Camel 3.0 discussion, and he > could be a key figure in getting the new API settled down, and help > splitup the camel-core into smaller pieces where it makes sense. When > that API is settled a bit and takes form, then we could look at the > "gap" from 3.0 to 2.x and put in migration guides, and possible some > @deprecations in the 2.x API. We should not do it the "wrong way > around" by experimenting with the 2.x API. > > > >> Hadrian >> >> >> >> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote: >> >>> Hi >>> >>> I am writing this mail with a "community hat" as well being a very >>> concerned Camel team member. >>> >>> The API in camel-core had a fair number of changes recently, which is >>> a strong concern from a community point of view. >>> Basically the community views Camel 2.x as an mature and well >>> established project, but also an "old and stable" product because of >>> Camel 2.x being 2+ years old. >>> >>> In summary the community wants in Camel 2.x >>> - NO CHANGES IN API >>> >>> The community do not care if class is named X or placed in Y etc. The >>> community care about that the class is kept named X and kept placed in >>> Y. >>> >>> That said, API changes is needed from time to time, and this is why >>> you accumulate API change ideas in roadmap wiki pages, TODO in the >>> source code etc. And possible some JIRA tickets. >>> >>> Then when a new major version is in the works such as Camel 3.0, then >>> those API changes can be executed. >>> In fact designing an API is a bigger challenge than at first thought. >>> Today you feel class X should be named and placed in Y package. To >>> days later it should be named X2 and placed in Z package instead. To >>> give amble time for API changes to settled down, and see how it "works >>> out" then milestone releases of the 3.0 is being released. This gives >>> the community and early adopters a changes to help out and give >>> feedback. This is common practice and how other projects do. >>> >>> The Apache Camel 2.x project is a very successful project and its >>> usage have reached beyond what you may see as a typical situation. We >>> have many other open source projects which integrate directly with >>> Camel in their products. We have other open source projects and >>> commercial products that is based on top of Camel, or using Camel >>> heavily internally. Their most likely use >>> the API in ways the typical end user does not. So bottom line the >>> exposed API is in use out there. >>> >>> The Camel team ove to the community to keep the API stable regardless >>> if a class could be renamed to X to have a bit better name etc. >>> >>> Likewise it does not give confort in the community if the API is kept >>> changing and their use of the API keeps being @deprecated. >>> So when they compile or upgrade to a new version, they get scared >>> because of the sheer number of @deprecate warnings. >>> It is a costly $$$ for any organization to change source code, as >>> often rigors testing and procedures kicks in, when the source code >>> must be changed. >>> >>> Likewise the Apache Camel subversion repository on trunk, is not a >>> personal * experiment* branch where the Camel committers should "play" >>> and move around with classes and whatnot. It would be better to setup >>> a branch or a personal project on github etc to work on the expriment >>> (for example as I did with the simple language improvements project). >>> >>> >>> From community point of view. Keep the API stable in our "old" and >>> beloved Camel 2.x product. >>> >>> From community point of view. Start a discussion about Camel 3.0, as >>> we think the Camel 2.x product is "old and stable". >>> But the community would like a brand new Camel 3.0 in early 2012. >>> >>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: cib...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: davsclaus, fusenews >>> Blog: http://davsclaus.blogspot.com/ >>> Author of Camel in Action: http://www.manning.com/ibsen/ >> >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
