Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 74.125.82.51 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=qL3EgRUcVFOwXoEe7yNGaKCymBRVfXaPmpHJ+X7XTutolCCfF68YAKQoKoesBvIW7z
         1Zj/FrIvH7LPGuSLST7mO+L+8NKoKJXMi5GVN3SFTy777bP+IaBk/CykwoJ1ifd9qXkV
         mIHFEP0wNT7hEzxuzMjwHecmD/Qv6/1JAIWDg=
MIME-Version: 1.0
In-Reply-To: <4D7C6931.9080708@gmail.com>
References: <71035BC3-A654-46C6-A07C-543D934EAFE0@gmail.com>
	<5FA4917B-FF0A-4BED-9BAF-8D09C25ABF2A@gmail.com>
	<AANLkTikzrRt4aiuc+pYnc_aY+xqp6K7ZaogPy__o1U0r@mail.gmail.com>
	<6C560567-ED9E-468C-925F-07618FD0E890@gmail.com>
	<AANLkTinhc634AJdB2U8kV+5p9=ZXscCF2mBZfnL3Yatv@mail.gmail.com>
	<BCCA9B57FEE894408005513A58B8CF1D061D053F6A@EXMBX01.SFP-Net.skyfillers.local>
	<AANLkTin2JDhTQNZa9F1nQs7kcNxw6zyyC7hiTiVKuDdn@mail.gmail.com>
	<9EEDF285-C4C7-4135-AB6F-4704905A8083@gmail.com>
	<4D7C6931.9080708@gmail.com>
Date: Sun, 13 Mar 2011 07:58:50 +0100
Message-ID: <AANLkTimvoTV3jAPkKStJquQcSkPsuWNo2YzY+uAQF+mQ@mail.gmail.com>
Subject: Re: [PROPOSAL]
From: Guillaume Nodet <gnodet@gmail.com>
To: "dev@camel.apache.org" <dev@camel.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 =E9crit=
=A0:
> +1 for the 3.a, and we need to make sure the Feature file is working righ=
tly.
>
> 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 th=
e 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 compatib=
ility with karaf 2.1.x will be broken at some point. There is no real diffe=
rence if we do it now or in 2.8.0 if 2.8.0 is released soon. If 2.8.0 is re=
leased 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 n=
egatively impact smx 4.4. Traditionally during the Camel lifetime we played=
 very nice with other communities, especially those that rely directly on C=
amel.
>
> 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 K=
araf 2.1.5 the compatibility will be restored.
> 3. We release Camel 2.7.0 either:
>  =A0a. 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 leave=
s a few weeks of incompatibility from the Camel release to the Karaf 2.1.5 =
release
>  =A0b. after the Karaf 2.1.5 release
>
> Personally I am ok with either 3a or 3b opting slightly towards 3a. If yo=
u 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> =
=A0wrote:
>
> Hi all,
>
> I think the same way as Claus. We should try to not add any functional ch=
anges 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 reall=
y 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 f=
ixes.
>
>
> 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 r=
elease. 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 t=
his 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=FCngliche Nachricht-----
> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com]
> Gesendet: Donnerstag, 10. M=E4rz 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> =A0=
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 Guillaum=
e's opinion, as a Karaf/OSGi expert.
>
>
>
> I really dont understand why you would think its "no brainer" to make suc=
h 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: =A0 =A0http://willemjiang.blogspot.com (English)
>  =A0 =A0 =A0 =A0 http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>

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