Hi Christian,

Here is one thing, when you introducing a new change (moving the classes around), you may updated the unit tests as well. But it could introduce some side effect to break the old codes, which may not covered by these unit tests.

It will take lot time for the user to fix that build failed even he dig the code or go through the API change list every often. We don't want user do it unless he upgrade to Camel 3.x. And we should keep it as less as possible.

I think that is Claus try to say when he wares the community hat.

Please think twice when you change the API, that is we learn from the evolution of Camel 2.x.

On 9/6/11 12:13 AM, Christian Schneider wrote:
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.





--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
         http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Reply via email to