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
