camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Sun, 25 Sep 2011 18:02:42 GMT
Willem, it sounds to me like you agree on most of the issues, correct? 
Comments inline.

Hadrian


> I think already stated my +1 for a new API module to break the cycle
> dependency of camel-core which was proposed by Christian.
Excellent.

> But I don't think we should ship the camel-api module in Camel 2.9, as
> it break the user experience,
Yes, no camel-api.jar in 2.9, camel-core stays the way it is.
>
> As you know there are lots of components which are not in the Apache
> Camel repository. Any incompatible change in the camel core may cause
> some trouble for the user when they upgrade to Camel 2.9.
Yes, we strive for compatibility.

> If we make the trunk as Camel 3.0, we can do more work than adding the
> compatible classes, and we can keep on thinking to add the other great
> feature of Camel3.0.
>
> The milestone release of Camel 3.0 could help us get the user feed back
> and we did it in development of Camel 2.0 without any trouble.
You are correct, but that's not what's being discussed. The question is 
when. The point was that a better time to start development for 3.0 is 
after 2.9 or possibly 2.10. Right now we do not know how 3.0 will look 
like. Starting development of 3.0 on trunk now and starting to figure 
out now what we want to do in 3.0 is disruptive and silly.

> If we fork another branch for the Camel 2.9.0. We will have much work to
> back port the patch. When we have some bug fix on the trunk, we have to
> merge patch back to Camel 2.9.x, 2.8.x, 2.7.x three branches. That is
> not a easy job to do.
I suspect that once 2.9.0 is out we will stop active maintenance of 
2.7.x and there will be at most one last release on 2.7.x. Iirc, we 
discussed to only provide community support for two past branches.


Mime
View raw message