Hi On Thursday, March 10, 2011, Christian Schneider <cschnei...@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.ib...@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 <hzbar...@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. > > The ticket its not a blocker for the 2.7 release. And it was already > scheduled for Camel 2.8. > And in terms of OSGi you have to be extra careful and test it more thoroughly > than a simpler fix in a plain Camel component. > The OSGi tests runs at the end of the CI process and thus they are more prone > to not be run due test failures in pre-existing components. > We all know it can be a little tricky to have CI 100% green. > Hence its a good practice to also run those OSGi tests locally once in a > while to ensure it works well. > > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
