camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 12:09:15 GMT
The question comes down to: is it worth taking the risk of breaking users
applications while this can be done safely in a major release.  Those
changes are not enabler, it's just cleaner at the end.  So while I think
those changes are good, they may be delayed until 3.0.

I don't really understand why not waiting a bit, given we have already a
breaking 3.0 planned already.
Trunk becoming 3.0 is actually a nice way to do that.  It allows developers
to continue working and making things cleaner as you do and keep a 2.9
branch for more non breaking changes / improvements / new features.

On Mon, Sep 26, 2011 at 13:17, Christian Schneider

> 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 (**
> jira/browse/CAMEL-4475 <>).
> 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.
> Christian
> 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
> --
> --
> Christian Schneider
> Open Source Architect
> Talend Application Integration Division

Guillaume Nodet
Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message