-1 at this point in time.
I have this topic a lot of thought during the past months. During a
transition, *if* you want to maintain backwards compatibility as much as
possible, there will necessarily be some bloat (code dealing with both
the new and the old).
It is much better to have this bloat towards the end of the 2.x line vs
the beginning of the 3.x line. Plus you get a bit of opportunity to
experiment. Camel 3.x would be the time to remove the old and deprecated
code and leave the new, lean one in.
This also gives users a longer time frame to make changes to their app
and prepare for the 3.x transition. I would use the trunk for 3.x only
after camel-2.9 or maybe camel-2.10.
Hadrian
On 09/23/2011 08:00 AM, Claus Ibsen wrote:
On Fri, Sep 23, 2011 at 1:36 PM, Christian Schneider
<ch...@die-schneider.net> 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
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
