camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <cschnei...@talend.com>
Subject AW: [VOTE] Release Apache Camel 2.7.0
Date Thu, 10 Mar 2011 13:31:40 GMT
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.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.

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.



Mime
View raw message