You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/03/11 21:24:14 UTC
[DISCUSS] Schedule for starting development on Camel 3.0.0
I assume somebody will take the stab to build Camel 2.10.0 in the next 4 -
6 weeks (if not, I will do it to be right here ;-) ).
At present we have 276 issues assigned to this version [1]. 209 are already
fixed.
I think this is a good time to discuss whether the next version will be
2.11.0 or 3.0.0.
*IF* the next version will be 3.0.0, we should have in mind that this
version:
1) Probably needs more time than our normal 3 month schedule for a new
minor version
2) Will break backwards compatibility and we want to provide a migration
path for our users where possible.
Because of this I would like to know:
- Do we have to deprecate some more API's which we plan to drop in Camel
3.0.0?
- Do we have to add some new API's stubs so that our users can start to
migrate to the new API in Camel 2.10.0 (if possible)?
Because of this I would like to see the following issues includes in Camel
2.10.0:
- CAMEL-4955 <https://issues.apache.org/jira/browse/CAMEL-4955> More and
more user want to run Camel with Java 7. If we postpone it to Camel 3.0.0,
we are very late with supporting Java 7. Apache Karaf supports Java 7 since
version 2.2.3 - available since more than 6 month...
- <https://issues.apache.org/jira/browse/CAMEL-4886>CAMEL-4778<https://issues.apache.org/jira/browse/CAMEL-4778>Also
more and more user would like to start using Spring 3.1., some did it
already. I think we should start to support Spring 3.1. officially in Camel
2.10.0.
And if the next version will not be Camel 3.0.0, I'm wondering for what we
are waiting... ;o)
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%222.10.0%22+AND+project+%3D+CAMEL
[2] https://issues.apache.org/jira/browse/KARAF-829
Looking for your opinions,
Christian
Re: [DISCUSS] Schedule for starting development on Camel 3.0.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I gave this some thought during the past days and here's what I suggest:
* trunk (camel-2.10.0) already has a bunch of fixes, new features,
components, so as Christian said, it makes a bunch of sense to release
on the regular schedule and not start 3.0 before this release. I think
first half of Apr is a good target and I volunteer to do the release.
Claus is right, there are a lot of things that require documentation
(some of it is in my lap) and we should focus on that.
* We know that 3.0 will break compatibility, hopefully not a lot and
with easy solutions. We also know that it will probably take some 6
months before we could release 3.0.
* if we'll need to have a 2.11 we'll probably only know in 2-3 months,
but with 2.9.x and 2.10.x still supported, probably not.
My preference would be to:
* release 2.10
* after that immediately create two branches 2.10.x and 2.11.x off the tag.
* keep trunk for 3.0 development
* the 2.11.x branch we could discard later on if not needed.
Alternatively we could leave trunk for 2.11 and create a 3.0 branch and
merge it later on into trunk, that'd work too.
We already know a lot of improvements we want to make for 3.0, we should
probably start adding details now, and use the next few weeks before the
2.10 release to create a roadmap.
My $0.02,
Hadrian
On 03/14/2012 07:18 PM, Christian Müller wrote:
> I have no rush with Camel 2.10.0. I would rather like discuss the schedule
> for Camel 3.0.0 (which of course depends on Camel 2.10.0). And I would like
> to discuss what we have to be done to start working on Camel 3.0.0.
>
> I created a new Jenkins build which will build the trunk with Java7 (Linux)
> [1].
>
> Do you mean we work in parallel on Camel 2.11.0 and 3.0.0 or do you mean we
> start with Camel 3.0.0 AFTER we released Camel 3.0.0? What are the features
> you expect to see in Camel 2.11.0 (and not in 2.10.x)?
>
> Most or all of our ideas make sense for me and I would like to see it. I'm
> only a bit vague about the schedules each of us have in mind.
>
> [1]
> https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.java7/
>
> Best,
> Christian
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: [DISCUSS] Schedule for starting development on Camel 3.0.0
Posted by Christian Müller <ch...@gmail.com>.
I have no rush with Camel 2.10.0. I would rather like discuss the schedule
for Camel 3.0.0 (which of course depends on Camel 2.10.0). And I would like
to discuss what we have to be done to start working on Camel 3.0.0.
I created a new Jenkins build which will build the trunk with Java7 (Linux)
[1].
Do you mean we work in parallel on Camel 2.11.0 and 3.0.0 or do you mean we
start with Camel 3.0.0 AFTER we released Camel 3.0.0? What are the features
you expect to see in Camel 2.11.0 (and not in 2.10.x)?
Most or all of our ideas make sense for me and I would like to see it. I'm
only a bit vague about the schedules each of us have in mind.
[1]
https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.java7/
Best,
Christian
Re: [DISCUSS] Schedule for starting development on Camel 3.0.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Mar 11, 2012 at 9:24 PM, Christian Müller
<ch...@gmail.com> wrote:
> I assume somebody will take the stab to build Camel 2.10.0 in the next 4 -
> 6 weeks (if not, I will do it to be right here ;-) ).
> At present we have 276 issues assigned to this version [1]. 209 are already
> fixed.
>
Yeah but I wonder if we will be ready then? Camel 2.10 seems to have a
lot of new components, which is still in development.
Or lacks proper documentation etc. So I suggest the ppl who work on
these components to focus on getting it done.
Alternative we will have to remove some components from the release
kits - we do not want to release incomplete components (incomplete =
also if no docs)
> I think this is a good time to discuss whether the next version will be
> 2.11.0 or 3.0.0.
>
> *IF* the next version will be 3.0.0, we should have in mind that this
> version:
> 1) Probably needs more time than our normal 3 month schedule for a new
> minor version
> 2) Will break backwards compatibility and we want to provide a migration
> path for our users where possible.
>
> Because of this I would like to know:
> - Do we have to deprecate some more API's which we plan to drop in Camel
> 3.0.0?
Its often easier to @deprecate when we actually get started working on
Camel 3.0.
And do an actual change, which warrant a @ deprecation in 2.x.
> - Do we have to add some new API's stubs so that our users can start to
> migrate to the new API in Camel 2.10.0 (if possible)?
>
See above.
> Because of this I would like to see the following issues includes in Camel
> 2.10.0:
> - CAMEL-4955 <https://issues.apache.org/jira/browse/CAMEL-4955> More and
> more user want to run Camel with Java 7. If we postpone it to Camel 3.0.0,
> we are very late with supporting Java 7. Apache Karaf supports Java 7 since
> version 2.2.3 - available since more than 6 month...
I suggest to setup a CI build at ASF that uses Java7.
Then we get test coverage using Java7 on linux and windows. And then
we can start fix any issues that exists due this.
I do not see a problem with supporting Java7 for Camel 2.10 onwards.
Only the OSGi world would need throughly testing, due
well its OSGi and surprises is always there. So we should have a CI
profile that runs the OSGi tests on the Java7 platform
with the Karaf version that supports Java7.
> - <https://issues.apache.org/jira/browse/CAMEL-4886>CAMEL-4778<https://issues.apache.org/jira/browse/CAMEL-4778>Also
> more and more user would like to start using Spring 3.1., some did it
> already. I think we should start to support Spring 3.1. officially in Camel
> 2.10.0.
>
Yeah would be nice to have support for both Spring 3.0 and 3.1 in Camel 2.10.
> And if the next version will not be Camel 3.0.0, I'm wondering for what we
> are waiting... ;o)
>
I think it takes longer time to do Camel 3.0, so I would suggest to
make room for Camel 2.11.
I suggest to taget Camel 3.0 for the end of 2012, eg Q4.
There is a fair number of internal optimizations and changes to the
routing engine that would be really good.
And to do that takes some time.
Also how the route model -> runtime is processed should be improved.
Currently there is a process where
interceptors, error handlers, on completions, etc. get woven directly
into the runtime routes. And the details is lost
from the route models that Camel exposes when running. So essentially
you cannot get a 100% 1:1 view of your Camel apps.
Combined with the routing engine optimizations, we can make this truly
1:1. And avoid to weave in the interceptors, error handers
in the route, but handle this during runtime. Then the runtime routes
and the design models can be 1:1.
This also avoids too deep stack frames.
And also allows to add/remove interceptors, etc at runtime to any
existing running Camel app. Which is some the SMX team
have requested. And people in the community. For example with Karaf
you can hot deploy a bundle that adds intercepting
to your Camel apps, and when you uninstall the bundle the interceptor
is gone. etc. This can also aid in other tooling
so you can hook in a diagnostic tool which can do more deep dive
investigations etc.
Also the route DSL should be tighten up a bit. Today its a bit too
lose, so you can specify onException in many areas where it does not
make sense.
Camel is kinda forgiving, and kinda "fix this itself" by adjusting the
model before its runtime created. But we would like to avoid this and
do no changes
to the design model at all, so we can have a 100% view of the route models.
We got some ideas for the Camel 3.0 sketched here
http://camel.apache.org/camel-30-roadmap.html
Also years ago we talked about to make the Message API immutable and
use a copy facade pattern
http://camel.apache.org/camel-2x-speed-optimizations.html
We may wanna take a 2nd look. Although we have optimized the logic a
fair bit to avoid excessive defensive copies
of the message during routing.
> [1]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%222.10.0%22+AND+project+%3D+CAMEL
> [2] https://issues.apache.org/jira/browse/KARAF-829
>
> Looking for your opinions,
> Christian
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/