camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Fri, 23 Sep 2011 13:59:59 GMT
I think the main concern of Christian is he afraid Camel 3.0 won't have 
much user to use, and  he explain us the recent back ports of Camel 
2.8.2 is because of the API change in Camel 2.9-SNAPSHOT.

How about we treat the Camel 2.9 as the Camel 3.0-m1. When we developed 
Camel 2.0, we actual did three mile stone release to fill the gap of 
the API change.
For the user who want to do some release just after Camel 3.0 RC is 
out, he can keep using Camel 3.0 mile stone release.
For the user who just want use the stable Camel 2.x, he can chose Camel 
2.8.x, as we already did a lot of merge of on the Camel 2.8.x branch.

Camel 3.0 Mx can tell the user what API change will be made, and we can 
removed the @Deprecates API when the Camel 3.0 is shaped.

Any thoughts ?

On Fri Sep 23 21:12:34 2011, Christian Schneider wrote:
> Well I donĀ“t think that works.
> If we add the @Deprecated annotation in the old code but we do not add 
> the new code then people can not really move their code easily.
> @Deprecated only makes sense if the new and the old code are present 
> at the same time. This can only be done in 2.x as we want to remove 
> the @Deprecated stuff in 3.0.
> So if you want an easy upgrade path for users then we have to do these 
> changes in 2.9 or 2.10. I think the current trunk should mostly work 
> for users.
> If some third party manipulates the byte code on implementation 
> classes like DefaultChannel then this can not be our problem. The 
> camel API is org.apache.camel and org.apache.camel.spi. Unfortunately 
> there are currently references to impl classes from the API which 
> makes our current API quite broken and we need to fix that. My recent 
> commits and my current issues solve that. See:
> -
> -
> Once we have those in the trunk we should have a good base for people 
> to slowly migrate away from @Deprecates while staying on 2.9. Then 
> they can easily switch to 3.0.
> So my proposal is to create a 2.9.0-RC1 from trunk quite soon and let 
> people test it. We can then do the necessary fixes. IF say 95% of 
> users can upgrade without changes then I think that is ok for a minor 
> release.
> It is not really necessary to be 100% compatible.
> Christian
> Am 23.09.2011 14:00, schrieb Claus Ibsen:
>> On Fri, Sep 23, 2011 at 1:36 PM, Christian Schneider
>> <> wrote:
>>> Hi Claus,
>>> we could do this but it would mean that all the compatibility 
>>> measures I put
>>> in place are in vain.
>> Its not in vain. Because when the API in Camel 3.0 is becoming clear
>> to us that this is what we want.
>> I guess many of the changes you have done, is already clear and a good
>> step in the right direction.
>> Anyway what I say is that the pieces of the API which are going to be
>> like that for Camel 3.0, we can then
>> add @deprecated in the 2.x code. And put in code from 3.0 as
>> replacement for the old @deprecated code.
>> We should of course do this with care, so the 2.x codebase can be run
>> fine as is, or fine if some end users start using the replaced API.
>> That means the 2.x codebase is fully API backwards compatible and
>> people can safely use their existing 3rd party Camel components,
>> interceptors,
>> any other other SPI adapters and whatnot they may have developed.
>> There are also commercial vendors (not FuseSource) who does byte code
>> instrumentation on the current API,
>> which is now broken on trunk (one example would be the DefaultChannel
>> class is moved).
>> And you cannot blame them as the API in camel-core is open and
>> available in the JAR file.
>>> As far as I understand it we want to remove all @Deprecated stuff in 
>>> camel
>>> 3.0. That means that people will have a quite incompatible update if 
>>> we do
>>> not prepare well for it.
>> Well we want for sure to remove the @deprecated stuff that has been
>> marked as @deprecated in the current 2.8.0 release.
>> In terms of removing additional @deprecated stuff, I think we should
>> do what makes the best for the community.
>> I am sure many pieces can be removed asap, others may take 6 months
>> etc. Its really whats best for the community.
>> Or maybe it would be possible for Camel 3.0.0 to create a camel-legacy
>> (find a better name for the JAR) which is an adapter
>> to make using Camel 2.x components/interceptors/SPI stuff and whatnot
>> possible to run with the new Camel 3.0 API.
>>> So my strategy is to create these compatibility stubs of old classes 
>>> that
>>> allow people a smooth transition. Of course this only works if a 
>>> release is
>>> made that
>>> contains the old and the new classes so people can slowly migrate. 
>>> If we do
>>> not release a 2.9.0 with the current trunk contents we will make it 
>>> much
>>> more difficult for people.
>>> Of course we could also do a 3.0 release with the @Deprecated in 
>>> place and
>>> remove them in 3.1 but then 3.1 would be the real major release ... 
>>> so I am
>>> not sure this would be a good idea.
>> Another goal for Camel 3.0.0 with the API changes would be that we can
>> formalize the API officially.
>> We can then split up the core into smaller pieces, and have a
>> camel-api JAR (or whatever a good name could be )
>> which has the end user API. Then from Camel 3.0.0 onwards we have a
>> much better platform to keep a good and stable API for the
>> large and growing Camel community.
>>> Christian
>>> Am 23.09.2011 13:13, schrieb Claus Ibsen:
>>>> Hi
>>>> I would like to propose that Camel source code currently on trunk is
>>>> to be Camel 3.0.0.
>>>> And the current code on the 2.8.x branch is to be used for the 2.x
>>>> lifetime of Camel.
>>>> The reason for this can be summarized as:
>>>> 1) All the API changes on trunk, and still to be done API changes
>>>> 2) Preserve Camel 2.x API stability
>>>> 3) Camel 2.x continue as usual
>>>> 4) Camel 2.x is already 2+ years old.
>>>> 5) The community would expect work on Camel 3.0 starting soon.
>>>> By letting the trunk code be targeted for Camel 3.0.0, we open the
>>>> ability to refactor the API more freely,
>>>> and without causing trouble for our large group of 2.x Camel users,
>>>> who are not expecting API changes in the camel-core at all.
>>>> Likewise the latest merges on the 2.8.x branch is already including
>>>> new features and other improvements,
>>>> which is a good offset for Camel 2.9.0. We can of course backport "the
>>>> missings" from trunk such as:
>>>> new components, and other improvements, new features, which we think
>>>> is worthwhile
>>>> and that the community would like to have in the Camel 2.9 release.
>>> -- 
>>> Christian Schneider
>>> Open Source Architect

Blog: (English) (Chinese)
Twitter: willemjiang 
Weibo: willemjiang 

View raw message