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.
