camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [DISCUSS] Closing down for the 2.8.0 release
Date Thu, 07 Jul 2011 02:14:47 GMT
On 7/6/11 1:55 PM, Christian Schneider wrote:
> Hi Willem,
> I can explain a bit from my experience as a user of Camel and CXF at my
> former employer regarding patch releases.
> We updated our stack every 6 to 8 months. With CXF this mostly simply
> worked. When some bug was detected we could create an issue and help fix
> it. It went into the next patch release and we could
> update to this one instead of the feature release.
> With Camel it was different. Every new release had a lot of new features
> and changes. So we almost every time found a bug in the release that
> prevented us to switch or that was a problem in production that needed
> to be addressed. What went very well in Camel was reporting and fixing
> bugs. I think Camel is probably the project I used where fixes to bugs
> were made fastest. The problem was that the fix was only on trunk. Then
> later it was incorporated into the new version. So my first strategy was
> to update to the most current camel release when a bug was found and
> fixed. The problem was that we almost every time found another problem
> in the new release.
> So what I did in the end was building our own release with the patches
> to the bugs we had. This worked very well but not every customer wants
> to do this.

Camel is involved the very fast if you compare it with CXF.
There could be more than 300 issues resolved in one major release of 
Camel. CXF is more stable after more than 5 years development, I can 
easily merge my patch for CXF trunk to 2.4.x and 2.3.x without changing 
anything. But if you merge the bug patch from Camel 2.8-SNAPSHOT to 
Camel 2.6.x, you may hit lots of conflicts.

I don't want give the customer false assumption that we do regular patch 
release for the every major release of Camel from now on. I just want 
user to move on to the new major release of Camel and we can promise 
them we keep fixing the bugs in the trunk if they report it.
> Patch releases like 2.7.3 give the customer the fixes they need without
> the breaking changes that cause new bugs. So from a customer standpoint
> patch releases are very valueable. Of course they make life for us more
> complicated so I think we should mostly only support one patch release
> and one feature release at the same time.

I agree we should do the the patch release for any security reason, 
because we take this responsibility without any condition.

>Of course a company like Fuse
> or Talend can also do patch releases on their own but I think it is
> better to have these releases at apache so it is transparent to the
> customer what is in each release and he has no fear of vendor lock in.
Current we don't have any other rule for the patch release of 2.7.x, 
even 2.8.x. I bring this question out is I don't want to give the user a 
false promise that 2.7.x patch release has all the bug patches those we 
found in the new major release of 2.8.0 etc.

> Christian
> Am 06.07.2011 04:09, schrieb Willem Jiang:
>> Hi Hadrian,
>> I think we are ready for the Camel 2.8.0 release.
>> But I'm not sure why you are still planing to do the patch release for
>> the 2.7.x as we never do this kind small patch release unless it
>> relates to a serious security issue before.
>> Can we just let the people move on to Camel 2.8.0 instead of confusing
>> about what's difference between the Camel 2.8.0 and Camel 2.7.3 ?
>> On 7/5/11 12:11 PM, Hadrian Zbarcea wrote:
>>> Karaf 2.2.2 is now available and Willem did the upgrade. I think we can
>>> get ready to start the release. Are there any other issues that must go
>>> into 2.8.0?
>>> I would also build a 2.7.3 at the same time, there are a few fixes and
>>> improvements, including some around xmlsecurity.
>>> Thoughts?
>>> Hadrian
>>> On 06/30/2011 11:07 PM, Willem Jiang wrote:
>>>> Hi,
>>>> I just applied the patch into trunk.
>>>> On 7/1/11 12:36 AM, Donald Whytock wrote:
>>>>> On Thu, Jun 30, 2011 at 12:35 PM, Donald Whytock<>
>>>>> wrote:
>>>>>> Just a reminder...CAMEL-3948 is marked as fixed, but the current
>>>>>> trunk
>>>>>> still needs my final patch.
>>>>>> Don
>>>>>> On Thu, Jun 30, 2011 at 2:46 AM, Jean-Baptiste
>>>>>> Onofré<> wrote:
>>>>>>> Hi Claus,
>>>>>>> Regarding Karaf 2.2.2, I've released OPS4J dependencies yesterday.
>>>>>>> Jamie
>>>>>>> will cut off the release this afternoon.
>>>>>>> Regards
>>>>>>> JB
>>>>>>> On 06/30/2011 08:31 AM, Claus Ibsen wrote:
>>>>>>>> Hi
>>>>>>>> Okay the JIRA roadmap for Camel 2.8 seems good now. There
is 2 open
>>>>>>>> tickets.
>>>>>>>> -
>>>>>>>> -
>>>>>>>> CAMEL-3774 is about generating the manual and is assigned
>>>>>>>> Hadrian.
>>>>>>>> CAMEL-4144 is about upgrading to Karaf 2.2.2. That release
is in
>>>>>>>> progress.
>>>>>>>> So by good chance we should be able to pickup that version
when its
>>>>>>>> released.
>>>>>>>> Alternatively we can stick to Karaf 2.2.1 which works fine.
>>>>>>>> (CAMEL-4144 is about some maven validate goal that would
>>>>>>>> Karaf
>>>>>>>> 2.2.2 to pickup a fix in Karaf, but running Camel in Karaf
>>>>>>>> absolutely fine)
>>>>>>>> The CI servers also seems good. Although they tend to run
out of
>>>>>>>> memory at the end, such as when testing the examples. But
those are
>>>>>>>> the last piece of the build, and thus all components tests
>>>>>>>> I suggest that when Karaf 2.2.2 is out we git it a few spins
>>>>>>>> the CI
>>>>>>>> servers and then start cutting the Camel 2.8 release. Would
>>>>>>>> good to
>>>>>>>> get it out before the summer vacation starts. As well its
>>>>>>>> than 3
>>>>>>>> months since Camel 2.7 was released.
>>>>>>>> On Mon, Jun 27, 2011 at 9:35 AM, Claus Ibsen<>
>>>>>>>> wrote:
>>>>>>>>> Hi
>>>>>>>>> Okay we should really start focusing on getting the last
>>>>>>>>> which
>>>>>>>>> has been assigned for 2.8 release done now.
>>>>>>>>> There is about 350 tickets on the roadmap, so its going
to be the
>>>>>>>>> biggest release, since 2.0 went GA.
>>>>>>>>> So please take a look at your assigned tickets and get
>>>>>>>>> done, or
>>>>>>>>> move them for 2.9.
>>>>>>>>> Then keep eyes on CI servers and help fix any test failures,
so we
>>>>>>>>> have green builds.
>>>>>>>>> The summer vacation period is approaching so we should
IMHO get
>>>>>>>>> the
>>>>>>>>> 2.8 release out early next month if possible.
>>>>>>>>> On Thu, Jun 9, 2011 at 2:47 PM, Hadrian
>>>>>>>>> Zbarcea<>
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I would propose starting to close down and prepare
for the 2.8.0
>>>>>>>>>> release
>>>>>>>>>> in
>>>>>>>>>> 2-3 weeks. There are already 282 issues for 2.8.0
and chances are
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> over 300 by the release time, probably setting a
new record.
>>>>>>>>>> As of now there are 17 issues unresolved, a few of
them almost
>>>>>>>>>> done, so
>>>>>>>>>> by
>>>>>>>>>> next week I assume there'll be significantly less.
I would
>>>>>>>>>> suggest
>>>>>>>>>> shifting
>>>>>>>>>> the focus from adding new features to stabilizing
the build. If
>>>>>>>>>> there
>>>>>>>>>> are
>>>>>>>>>> any issues you know of that you think absolutely
must be in 2.8.0
>>>>>>>>>> please
>>>>>>>>>> shout and ask for help if needed (especially non
>>>>>>>>>> subscribing
>>>>>>>>>> to
>>>>>>>>>> this list).
>>>>>>>>>> Thoughts?
>>>>>>>>>> Hadrian
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> -----------------
>>>>>>>>> FuseSource
>>>>>>>>> Email:
>>>>>>>>> Web:
>>>>>>>>> Twitter: davsclaus, fusenews
>>>>>>>>> Blog:
>>>>>>>>> Author of Camel in Action:

Blog: (English)
Twitter: willemjiang
Weibo: willemjiang

View raw message