Hi Guillaume,
there are several changes I did recently. The main issue perhaps is the
current issue I opened:
https://issues.apache.org/jira/browse/CAMEL-4417
This of course a very sensible area and I plan to do this very carefully
and will create a patch to discuss before I change something.
To a lower extend all my recent changes have the risk of introducing
incompatiblilty. I tried to introduce deprecated stubs whereever I
thought they would be needed. To further lower the risk to users I think
we could do a 2.9 release candidate and add more compatibility classes
where people demand them.
The idea I follow is to remove the deprecated classes in 3.0 but
introduce them now. So people have time to change their code while using
2.9.x and then have a smoother transition.
This would be especially good for component developers. At the moment
their components are targeted for 2.x. So with the changes in 2.9 they
could at some point change their components to the new api
and then they would be compatible with 2.9.x and 3.x.
Christian
Am 05.09.2011 17:51, schrieb Guillaume Nodet:
Can one point to the exact changes we're talking about here?
If those are fully compatible through using deprecation, I don't see
any major problem.
However, I don't think we should introduce incompatible changes unless
really required, especially as we *are* planning to do a 3.0 some time
in the near future, and all breaking changes should be put there.
Else, there's no need to call it 3.0 and 2.10 would be fine too.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
