camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [PROPOSAL]
Date Sun, 13 Mar 2011 06:58:50 GMT
That's actually a great suggestion and this would be even better imo.


Le dimanche 13 mars 2011, Willem Jiang <willem.jiang@gmail.com> a écrit :
> +1 for the 3.a, and we need to make sure the Feature file is working rightly.
>
> I think we can provide another Feature.xml file like we did in Camel 2.6.0 to support
the spring 2.5.x.
> In this case we could just provide another Features.xml which supports the Karaf 2.1.4
etc.
>
> Willem
>
> On 3/12/11 2:07 AM, Hadrian Zbarcea wrote:
>
> We knew this patch will go in, now or 2.8.0 which meant that the compatibility with karaf
2.1.x will be broken at some point. There is no real difference if we do it now or in 2.8.0
if 2.8.0 is released soon. If 2.8.0 is released much later, we give users something that is
java6, spring3, etc and also karaf 2.1 compatible (which 2.6.0 does already anyway), but we
could negatively impact smx 4.4. Traditionally during the Camel lifetime we played very nice
with other communities, especially those that rely directly on Camel.
>
> That said, my proposal is this:
> 1. We keep Jean Baptiste's patch.
> 2. JB opened and KARAF-505 and will commit a patch soon. As of the next Karaf 2.1.5 the
compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>   a. after a few days of testing (per Christian proposal, +1'd by Claus); the only impact
of the patch is using the new obr features in Karaf 2.2.0 (which was tested, contrary to allegations),
no other impacts; this leaves a few weeks of incompatibility from the Camel release to the
Karaf 2.1.5 release
>   b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If you have other
proposals or a preference please speak up. I hope us to be in position to make a decision
early next week.
>
> Thanks,
> Hadrian
>
>
>
> On Mar 10, 2011, at 8:08 PM, Claus Ibsen wrote:
>
>
> Hi
>
> On Thursday, March 10, 2011, Christian Schneider<cschneider@talend.com>  wrote:
>
> Hi all,
>
> I think the same way as Claus. We should try to not add any functional changes a few
days before a release. That is the only way to make sure people have time to run their tests
against the code base to be released.
> I was already hesitant to commit my patch for the servlet on friday.
>
> So I think we have two options for the features.xml issue. If it is really important
for 2.7.0 we do a new release with it included in some days. If not we cut a release now with
the reverted version, perhaps with Willems fixes.
>
>
> Yeah as christian says i think we got two options.
> 1) re cut release without the features patch
> 2) apply the patch and postpone the release for a week or longer, to
> allow throughly testing of karaf 2.2.0 and camel 2.7. This also mean
> camel 2.7 is not backwards comp. With karaf 2.1.x as stated by jean in
> the given jira ticket.
>
> if we go for 2 then we could fulfil the goal for apache smx 4.4 which
> needs a camel with karaf 2.2 and that features patch. Although we are
> very likely to be able to cut a new camel 2.8 release beforehand.
>
> I am traveling for the next two weeks, so you guys can have fun
> without me policing.
> In light of this and the fact smx 4,4 need the patch, i am okay for
> either option.
>
>
>
>
> So I think what we should do is define a code freeze some days before a release. During
this time we should only commit bug fixes but not functional changes. In a less formal way
we already do this.
> If we think this could slow down progress on the trunk then we could at this point create
a branch for the release.
>
>
>
> Yeah we are usually good at having a slowdown up til the release is
> cut. This time we had five or more days, which was really good. The
> last major func. Change was that servlet improvements which imho is a
> very good improvement. After this we fixed all the maven archetypes so
> they are working again. Other than that its bug fixes and test fixes
> leading up till the cut time.
>
>
>
>
> Christian
>
> -----Ursprüngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Donnerstag, 10. März 2011 11:44
> An: dev@camel.apache.org
> Betreff: Re: [VOTE] Release Apache Camel 2.7.0
>
> On Thu, Mar 10, 2011 at 11:12 AM, Hadrian Zbarcea<hzbarcea@gmail.com>  wrote:
>
>
>
> I see now that Willem already reverted the patch, not clear why, I assume just based
on your feelings. I would be very interested in seeing Guillaume's opinion, as a Karaf/OSGi
expert.
>
>
>
> I really dont understand why you would think its "no brainer" to make such a big change
"seconds" before you cut the release.
> You are usually very good and careful when you do the releases.
>
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>          http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message