> Christian: > 1. Each component release needs a vote. So with the 100+ components we would > have 100 votes instead of one vote for a camel release.
CR-01 release of all components would be performed together with core. Component releases higher than CR-01 would be performed seldom, usually on explicit user request. In practice there will be only several of additional CRs between core releases. > Christian: > So a support request may read like: I am using camel-core 3.0.1 with > camel-jms 2.5.4 and camel-jetty 3.2.2 but sometimes get exception xy. This > is quite hard to support. No, it can't look like this, as my CR qualifier applies only to the certain version of core release. You example would look like: I am using camel-core-3.0.1 with camel-jms-3.0.1-CR-01 and camel-jetty-3.0.1-CR-02 but sometimes get exception xy. And this is quite easy to support as only jetty component has been additionally released. Using Maven version qualifiers is not the same as using totally independent versioning for each component, as qualifier is bound to the particular release version of the core. > Maruan: > you nailed it. The idea of the marketplace is to give up responsibility. > Apache Camel is responsible for the > foundation (software, infrastructure, procedures). The component developer has > responsibility for the component. If we follow this path, we will end up with bare core and marketplace full of lousy components. Take a look at Grails plugin repository [1]. There are hundreds of them, but half of them don't work well with the latest Grails. Grails developers cut the core release and don't care about the plugins. This approach leads to situations when user cannot upgrade core Grails because plugins stop to work, or even worse, work incorrectly. The part of success of Camel is that it supports almost every technology and supports it well. Our components are well tested against the core. You can safely update Camel core and don't mind that components will go crazy. Our great and stable components repository is something that makes us really competitive comparing to Spring Integration or Mule. They got EIP, JMS, WebServices and e-mail support as well. In my humble opinion end users don't care about the polished core. What they care about is the stable, polished and wide pallet of components they can use out of the box. End users get excited when they see the impressive list of components we support out of the box. If we drop our components portfolio, we would be no better than Spring Integration. Our core could be designed better, but will user care about it? Is there really a problem with components maintenance and releases? Majority of them doesn't change. They don't block the releases. In my opinion we should focus on speeding up the delivery of the components instead of dropping support for the important part of our success. [1] http://grails.org/plugins -- Henryk Konsek http://henryk-konsek.blogspot.com
