Hi Claus,
we could do this but it would mean that all the compatibility measures I
put in place are in vain.
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.
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.
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
