camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Bength <>
Subject Re: [DISCUSS] Camel release cycle (was: Camel 2.5.1 release)
Date Thu, 16 Dec 2010 14:35:20 GMT

I am just a humble camel user who also develop some custom add-ons and
(will post about that later when I finally get some time..)

While Apache should not take the place of supporting companies like FuseSource
(who rolls their own releases with cherry picked patches)
I tend to agree with Hadrian that Camel should contemplate being (at
least) *open* for
Because as it is now, if I find a problem now, that you have a fix for
I can do a couple of things:
1) roll my own relase with back port of the fix.
2) work around the issue more or less beautifully
3) wait for next camel release

all course have some drawbacks, but i suspect most would use §2 until
§3 happens.
but as the development of camel is progressing quite rapidly, new
behavior, components and dependencies
are introduced all the time. For many of us, there is not always an
option to just swap camel version.
If say, you have a system in production that is working well, except
that you need to introduce
new use cases or integrations without risking everything else.

Having a bug fix release branch that some fixes are back-ported to,
would also ease the
"progression rate anxiety" of the Camel committers too, perhaps (if
they care about their users' problems)

Of course, I see the problems with committer workload, configuration
management and qa, etc
being there myself so I'm not really complaining, just chiming in :-)
(and using hand rolled patches)

On Thu, Dec 16, 2010 at 11:21 AM, Guillaume Nodet <> wrote:
> The good news is that we've found a workaround in ServiceMix so we
> don't need a minor release anymore :-)
> I think keeping our current 3 months release cycle as it has proven to
> work very well those last years.
> On Wed, Dec 15, 2010 at 19:33, Hadrian Zbarcea <> wrote:
>> Hi Willem,
>> Personally I am in favor it and I could start the release builds immediately. However:
>> 1. There is no camel-2.5.1 branch so one would have to be created. We could create
a camel-2.5 branch off of the 2.5.0 tag.
>> 2. There is no precedent for having patch releases in Camel (3rd digit). It doesn't
mean we cannot start it (I would like that actually) but we need to discuss it and agree on
>> 3. If we do that it would make sense to have more formal support cycle for a version.
Camel imho got a maturity level that almost requires it.
>> My preference would be a 6 weeks release cycle, meaning 2 releases per quarter. Patch
releases should be 100% backwards compatible (including dsl), no version upgrades for dependencies
and should only include bug fixes. Minor releases (2nd digit) could bring new features, components,
dependency upgrades (as we do it now). Major releases will be rare, but 3.0 is coming up.
>> Thoughts/ideas/preferences?
>> Hadrian
>> On Dec 15, 2010, at 9:30 AM, Willem Jiang wrote:
>>> Hi,
>>> I just found some issues[1][2] of camel-cxf in Camel 2.5.0 which cause the camel-nmr
component tests[3] failed. I didn't find a way to work round the camel issues without changing
the code camel.
>>> As you know ServiceMix 4.3.0 releasing is on the way, if we let ServiceMix pick
up the latest Camel 2.6.0, there will be not just waiting for the Camel 2.6.0 release issue.
ServiceMix also need to upgrade it's CXF version to 2.3.x and prepare the bunch of new JAXWS,
JAXRS bundle release.
>>> Now I propose to do Camel 2.5.1 release myself by merging the upper camel fix
into 2.5 branch, In this way, we can fix the camel-nmr issue without blocking the ServiceMix
4.3.0 release.
>>> Any thoughts ?
>>> [1]
>>> [2]
>>> [3]
>>> --
>>> Willem
>>> ----------------------------------
>>> FuseSource
>>> Web:
>>> Blog: (English)
>>> (Chinese)
>>> Twitter: willemjiang
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

View raw message