On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider <ch...@die-schneider.net> wrote: > Hi Claus, > > I am trying to give the community a smooth transition to 3.0 by my current > changes. > > Whereever possible I use a deprecated class in the old place. So someone who > changes to camel 2.9.0 should have no problems. > He will see deprecation warnings though and this is a good thing. It will > allow him to then adapt to the changes while staying on 2.9.0. Then when > he switches to 3.0.0 he will again have almost nothing to change. > > If we do not do changes now and do everything in 3.0 then people will have a > very incompatible upgrade from 2.x to 3.0. So I think now with 2.9.x being > the last 2.x minor version it is exactly the right time to do these changes. > Of course you are right that it is very difficult to do the design right. So > we should look at it together and discuss how things should look like. If we > wait with this till 3.0 then it is too late. If I experiment in a private > branch then no one will look at the changes > and no discussion will occur. >
What do you mean by 3.0 is too late? So you would rather take the entire Camel community as "hostage" (sorry I cant find a better word) by API changes directly on the trunk? Than use a new branch which gives you, the Camel team and people from the community time to work on the API without side effects, of our existing community users. Frankly this is how other projects do it. They create a new major release where they do non backwards API changes, key API changes which is needed to make the product better etc. Apache ServiceMix team have created a branch for their upcoming SMX 5.0 release. Apache Karaf team have created a branch for their upcoming Karaf 3.0 release. Apache ActiveMQ created a new branch for their upcoming ActiveMQ 6.0 release. (This release is actually a total overhaul and based on a new architecture) Neither of those projects created a lot of API changes prior in the current release branches, *before* they got started on their new major release. If you look outside Apache, the for example the Spring framework do neither this. If we compare Camel and Spring then the releases would roughly match up as below. Notice that we in the Camel team have this history of doing a quarterly minor release, and hence why the versions match up as below: Camel 2.0 = Spring 3.0.0 Camel 2.1 = Spring 3.0.1 Camel 2.2 = Spring 3.0.2 Camel 2.3 = Spring 3.0.3 ... Not anytime in the Spring 3.0.x release have the Spring team started to move around classes and mark the API as @deprecated and whatnot, just because they want people a "smooth transition" to Spring 3.1. They actually respect the community and keep the API stable. Now imagine this use-case from which could be from the real life. Developer: We need to upgrade Camel in this production application Manager: Why? Developer: It fixes this bug we have, and also it improved this issue as well Manager: How long time will it take? Developer: I do not know, as the release notes say, that there is many API changes and non backwards compatible breakings Manager: Has this happened before? Developer: No this is the first time. I though Camel 2.x was an old, mature and stable product. Manager: Will this upgrade affect other products? Developer: Yes possible. We have those 3 custom in-house Camel components which most likely would be affected. Developer: And these components is shared by the 5 other Camel applications we have in production. And the 2 new projects we have in development currently. Manager: So you are saying that we need to upgrade Camel to fix this bug. But we cannot upfront have a qualified overview of the consequences? Developer: Yes Manager: So I need to quad-double my budget for this upgrade. And impose changes and risks in other projects as well. Manager: What would be the consequences for not upgrading? Developer: We have this bug in production Manager: Is there a workaround? Developer: Possible as the bug is fixed in a later Camel release. We may be able to patch the current version of Camel with the fix Manager: How long time will this take? Developer: Much less than upgrading Camel. Manager: Okay I want you to look into patching that bug, instead of upgrading. Manager: Hmm so you are saying that by relying on Camel in our business, we have this risk of upgrade pains, that is hard to estimate the consequences of, takes longer time, and costs more money Manager: I want a new team setup tomorrow that starts looking for alternatives for Camel. I don't want this problem in the future. > Christian > > > Am 05.09.2011 16:04, schrieb Claus Ibsen: >> >> 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. >> >> >> >> >> > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- 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/
