camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Camel 3 discussion] Components releases
Date Wed, 20 Feb 2013 14:31:46 GMT
Am 20.02.2013 14:53, schrieb Henryk Konsek:
>> 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.
Do we really need this then? If there is a bug in a component we can fix 
it in the next bugfix release of camel.
>> 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.
So why not use the bugfix version for this purpose?
A camel component should be designed in a way that it works with any 
bugfix release of camel.

So if camel-jms 3.1.2 has a bug we release camel 3.1.3 and it will work 
with a camel 3.1.2 installation.

>
>> 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?
The end user normallly does not see the quality of core. Still there are 
problems with it.
As we have no API the end user may use any part of core in his own code. 
So any change in core can break his code.... and he will blame camel.
The other problem with the quality of core is that it limits our ability 
to provide new core features and improve existing core features.
If you look at some parts of the core code you see that some new 
features or fixes are only implemented using ugly hacks. The reason is 
that the developer
feared to do a proper implementation as it would break compatibility. 
The only way to break this cycle is to create a slim API and make sure 
people only use the API.
This would require a big effort from our side but I think i is the only 
chance to perpare camel for the future. If we miss this chance camel 
will become a legacy project
that is rather maintained than developed. People will become 
increasingly frustrated and at some point a new project will take over 
as it can move faster.

>
> 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.
Not sure what is wrong with the speed of releases we have now. Real bug 
fix releases are no big issue and do not require too much testing.
Of course we might think about releasing only parts of camel in a bug 
fix release ... but I am not sure it would be worth the effort.

Christian

-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message