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:40:50 GMT
OK, I see the patch rule is based on the Talend customer.

On 7/6/11 9:32 PM, Daniel Kulp wrote:
> One other note:
> Talend  has customers on 2.7.x that are not likely to move to 2.8.0 any time
> soon.   As Christian pointed out, lots of companies use a 6-8 month cycle,
> Some longer, some shorter, and won't move off what they have for quite a bit
> of time.     Thus, no matter what, I am going to have to port some bug fixes
> back to 2.7.x.    There isn't anyway for me to avoid that (unless I tell my
> customers "too bad, no fixes" which would not go over well :-) ).   I COULD do
> the porting on some private fork of the Camel branches and deliver the fixes
> to the customers that way.   That's definitely a perfectly valid way to do it.
> In that case, all my work really would just benefit a small number of Camel
> users.  I'd MUCH MUCH prefer to do the porting here and allow my work to
> benefit the entire Camel community.   It's the exact same amount of work, just
> in a different place.  (well, I suppose if the fork is using git, it could be
> a little less work as merging with git is so much nicer and faster, but still,
> that's minor)
> Likewise for releases.  I could create private releases and stick them in a
> "talend" repository someplace (and in some cases, I may need to do that
> anyway), but I could also do roughly the same amount of work here (calling the
> vote is additional work here, but that's minor) and the entire Camel user base
> benefits.   In addition, the releases here would go to central which makes our
> customers happy. (no Nexus updates, firewall rules updates, etc...)
> In short, the incremental cost for *ME* to continue supporting the fixes
> branches that our customers are using is negligible.  There's really no reason
> to not do it.  It has an additional benefit of making other Camel users
> happier by providing more stable releases for them to use.   IMO, it's
> basically a "win-win" all around, or am I missing something?
> Dan
> On Wednesday, July 06, 2011 7:55:16 AM 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.
>> 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. 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.
>> 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
>>>>>>>>> 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
>>>>>>>>> (CAMEL-4144 is about some maven validate goal that would
>>>>>>>>> require
>>>>>>>>> Karaf
>>>>>>>>> 2.2.2 to pickup a fix in Karaf, but running Camel in
>>>>>>>>> is
>>>>>>>>> absolutely fine)
>>>>>>>>> The CI servers also seems good. Although they tend to
>>>>>>>>> out of
>>>>>>>>> memory at the end, such as when testing the examples.
>>>>>>>>> those are
>>>>>>>>> the last piece of the build, and thus all components
>>>>>>>>> fine.
>>>>>>>>> I suggest that when Karaf 2.2.2 is out we git it a few
>>>>>>>>> on
>>>>>>>>> the CI
>>>>>>>>> servers and then start cutting the Camel 2.8 release.
>>>>>>>>> be
>>>>>>>>> good to
>>>>>>>>> get it out before the summer vacation starts. As well
>>>>>>>>> more
>>>>>>>>> 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
>>>>>>>>>> tickets
>>>>>>>>>> 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
>>>>>>>>>> them
>>>>>>>>>> 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
>>>>>>>>>>> the 2.8.0
>>>>>>>>>>> release
>>>>>>>>>>> in
>>>>>>>>>>> 2-3 weeks. There are already 282 issues for 2.8.0
>>>>>>>>>>> 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
>>>>>>>>>>> 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
>>>>>>>>>>> committers
>>>>>>>>>>> subscribing
>>>>>>>>>>> to
>>>>>>>>>>> this list).
>>>>>>>>>>> Thoughts?
>>>>>>>>>>> Hadrian

Blog: (English)
Twitter: willemjiang
Weibo: willemjiang

View raw message