camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 11:17:02 GMT
Yes there are probably some undocumented changes. The question is though 
if they would hit anyone. That is why I would like to do a release 
candidate for 2.9. So
people can try to run their projects with the refactorings and we can 
even react before the first official 2.9 release.

About the SPI changes I propose 
( This would of course 
be a breaking change for anyone who actually uses these interfaces. The 
questions is though how many people
would be hit. If you look closely at the interfaces then Policy is the 
only one that is really likely to be used. The Debugger is probably also 
used especially for tests. These were the only two points where I had to 
do changes outside of camel-core to get the tests working.

So while there is a chance that people are hit the percentage may be 
small. If we then react fast or even before 2.9.0 and provide 
compatibitlity for people who report problems then I can imagine to make 
almost everyone happy with 2.9.0.


Am 26.09.2011 10:52, schrieb Claus Ibsen:
> On Sat, Sep 24, 2011 at 10:30 PM, Christian Müller
> <>  wrote:
>> That's exactly what I think, Hadrian.
>> A minor release has not to be 100% backwarts compatiple. Of course we try
>> our best to be 100% backwarts compatible in minor releases, but it should
>> not be a problem if we aren't, as long as we document the not backwarts
>> compatible changes.
> The API changes has not been fully documented. In fact there is a
> "disclaimer" in the release notes, saying something like.
> Hey we have changed the API a lot, and we kinda got lost in this
> process. We are sorry if you hit any API breakings.
> But tell us and we will try to add some stubs in the next release.
>> A micro/bugfix release has to be 100% backwarts compatible of course.
> The current 2.8.x branch is not 100% backwards compatible. There is
> API changes committed.
>> I prefer to release a 2.9.0 version after Christian S. (an may other) 99%
>> backwarts compatible changes/refactorings are done. Afterwards we can start
>> to develop 3.0.0 on trunk - with the time to play a bit with our new ideas
>> and the freedom to break existing APIs.
> Well if Christian did stop right now doing anymore API changes, then
> we may have a slight chance to not piss-off to many end users.
> But there is JIRA ticket assigned to him targeted for Camel 2.9.0,
> where he wants to do bigger API-breakings in the model / SPI packages.
> Likewise he moved classes / deleted classes (from camel-core) without
> marking any old classes as @deprecated, which gives people a chance to
> migrate over a amble period of time. So we end up in a catch-22
> situation.
Can you report the classes you found. If they are important to users I 
can provide stubs.
> So Camel end users may have developed in-house components /
> interceptors / management tooling / or whatever for Camel which you
> want to use for existing in production Camel 2.8 projects. And then
> also for new projects using Camel 2.9+. For that to work out, you
> would need to maintain 2 branches of your custom stuff as its not
> compatible with both 2.8 and 2.9+.
Yes that can be a real problem. So we should make sure there are not too 
many releases that change the API on the way to 3.0. On the other hand I 
think we should release often to get feedback. That is a difficult balance.

Christian Schneider

Open Source Architect
Talend Application Integration Division

View raw message