I am -1 for separate component releases. There are two problems:
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.
Of course it is less in practice as not every component is released
every time but still a lot of votes.
2. We need to support each release of a component for a certain time and
make sure it is compatible to camel core and other components in various
releases.
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.
Compare this to people who now say I am using camel 2.2.10 with
camel-jms and camel-jetty. Even my proposal would make support a lot harder.
I think it makes sense to have minor releases every let´s say 3 months
and bugfix releases for each supported minor release also about every
1-3 months. So if we support a minor release for a year
it means we have about 4 minor releases to support in parallel.
If we would theoretically release every component every 3 months or even
faster it would mean we have a gigantic number of branches and version
combinations to support. This is not manageable in my opinion.
Christian
Am 19.02.2013 23:21, schrieb Henryk Konsek:
Hi Christian,
How about a simpler model?
A component could specify the minimum camel core or better api in the future
it needs.
For example:
camel-jms 3.0 -> camel-core 3.0
camel-jms 3.1 -> camel-core 3.0
Unfortunately this approach doesn't address the problem that component
users still need to wait for core to be released if they want the
latest version of the component. The main issue I try to address is to
give the users faster access the to the released components without
waiting for the core release.
Best regards.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
