camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [DISCUSS] - API stability in Camel 2.x
Date Mon, 05 Sep 2011 16:13:40 GMT
Hi Guillaume,

there are several changes I did recently. The main issue perhaps is  the 
current issue I opened:
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.


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

Open Source Architect
Talend Application Integration Division

View raw message