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. 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. 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.
