You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2011/09/23 13:13:56 UTC
[DISCUSS] - Trunk as Camel 3.0
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.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Rob, if you are labeling what I said as a red herring, please re-read
and spend some time to understand what I said. I'll come back with a
more detailed answer later if need (but I am crossing my fingers and
hope that won't be necessary).
Hadrian
On 09/23/2011 10:13 AM, Rob Davies wrote:
>
> The reality is that users, want stability and they will be unwilling to move to versions above 2.8.x unless there's a compelling reason to do so. So if they know a 3.0 is in the works, they will wait till that version is GA before considering upgrading. So try to get them to transition easily by moving to 2.9 and 3.0 is a a red-herring. Much better to make the move to 3.0 now.
>
> On 23 Sep 2011, at 15:08, Daniel Kulp wrote:
>
>>
>> -1 - this makes no sense to me. Christian and Hadrian have done a ton of
>> work to make sure those changes are completely compatible for 2.x users while
>> also providing those users a glimpse into what 3.0 will look like and
>> providing migration paths for those users. That's a *good* thing.
>>
>> What I *would* be in favor of is:
>>
>> Create a 2.9.x (or just 2.x) branch off of trunk now to start the final
>> stabilizing and testing of that code base on that branch. Then make trunk
>> 3.0 and immediately remove all the @deprecated stuff there to start real work
>> toward the 3.0 release.
>>
>> Dan
>>
>>
>>
>> On Friday, September 23, 2011 1:13:56 PM Claus Ibsen wrote:
>>> 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.
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, September 23, 2011 3:13:02 PM Rob Davies wrote:
> The reality is that users, want stability and they will be unwilling to
> move to versions above 2.8.x unless there's a compelling reason to do so.
So let them stay on 2.8.x. We'll happily provide fixes for them. We have a
nice back porting process setup now. I have ABSOLUTELY no problem with that.
> So if they know a 3.0 is in the works, they will wait till that version is
> GA before considering upgrading. So try to get them to transition easily by
> moving to 2.9 and 3.0 is a a red-herring. Much better to make the move to
> 3.0 now.
I cannot see how providing a migration path for some users is a bad thing. I
specifically have customers asking for such a path as we move forward. They
want to stay on 2.x line for now (likely till 3.1, fear of .0's) but still
have a nice migration path for their app. (and no, using a 3.0-RC1 is not
acceptable at all)
Dan
> On 23 Sep 2011, at 15:08, Daniel Kulp wrote:
> > -1 - this makes no sense to me. Christian and Hadrian have done a ton
> > of work to make sure those changes are completely compatible for 2.x
> > users while also providing those users a glimpse into what 3.0 will
> > look like and providing migration paths for those users. That's a
> > *good* thing.
> >
> > What I *would* be in favor of is:
> >
> > Create a 2.9.x (or just 2.x) branch off of trunk now to start the final
> > stabilizing and testing of that code base on that branch. Then make
> > trunk 3.0 and immediately remove all the @deprecated stuff there to
> > start real work toward the 3.0 release.
> >
> > Dan
> >
> > On Friday, September 23, 2011 1:13:56 PM Claus Ibsen wrote:
> >> 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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Rob Davies <ra...@gmail.com>.
The reality is that users, want stability and they will be unwilling to move to versions above 2.8.x unless there's a compelling reason to do so. So if they know a 3.0 is in the works, they will wait till that version is GA before considering upgrading. So try to get them to transition easily by moving to 2.9 and 3.0 is a a red-herring. Much better to make the move to 3.0 now.
On 23 Sep 2011, at 15:08, Daniel Kulp wrote:
>
> -1 - this makes no sense to me. Christian and Hadrian have done a ton of
> work to make sure those changes are completely compatible for 2.x users while
> also providing those users a glimpse into what 3.0 will look like and
> providing migration paths for those users. That's a *good* thing.
>
> What I *would* be in favor of is:
>
> Create a 2.9.x (or just 2.x) branch off of trunk now to start the final
> stabilizing and testing of that code base on that branch. Then make trunk
> 3.0 and immediately remove all the @deprecated stuff there to start real work
> toward the 3.0 release.
>
> Dan
>
>
>
> On Friday, September 23, 2011 1:13:56 PM Claus Ibsen wrote:
>> 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.
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Daniel Kulp <dk...@apache.org>.
-1 - this makes no sense to me. Christian and Hadrian have done a ton of
work to make sure those changes are completely compatible for 2.x users while
also providing those users a glimpse into what 3.0 will look like and
providing migration paths for those users. That's a *good* thing.
What I *would* be in favor of is:
Create a 2.9.x (or just 2.x) branch off of trunk now to start the final
stabilizing and testing of that code base on that branch. Then make trunk
3.0 and immediately remove all the @deprecated stuff there to start real work
toward the 3.0 release.
Dan
On Friday, September 23, 2011 1:13:56 PM Claus Ibsen wrote:
> 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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Guillaume Nodet <gn...@gmail.com>.
It seems to me this discussion is mostly related to how / when introduce
changes in the API.
One possible way would be:
* micro release: no api change
* minor release: 100% backward compatible api changes
* major release: incompatible changes
Now, I agree with Hiram in that @deprecated would be better introduced in
3.0 and removed in 3.1 (or even later in 4.0) rather than have them
introduced in 2.9 and removed in 3.0. The reason is that people are not
supposed to do major migration work between minor releases, so if we
introduce the chagnes in 2.9, it means they *should* change when upgrading.
It seems slightly better to make them change when upgrading to 3.0 (and
give them a bit of time to do so).
On Fri, Sep 23, 2011 at 13:13, Claus Ibsen <cl...@gmail.com> wrote:
> 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.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Rob Davies <ra...@gmail.com>.
+1
On 23 Sep 2011, at 12:13, Claus Ibsen wrote:
> 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.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 26, 2011 at 2:36 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Again, it seems to me that you're implying Claus has problems with the
> changes you did.
> Reading his emails, I think the problems are more related to which branch /
> when do the changes rather than if we do the changes.
>
My local maven repo is trashed, so I am rebuilding my sources, so I
got a bit time on the mail.
So why it appears as I respond so soon.
Yes Guillaume is spot on.
I am in favor of cleaning up the API in camel-core.
However I would prefer this to happen on another branch, which would
become Camel 3.0.
And keep the current 2.x as it has been for the last 2 years.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Guillaume Nodet <gn...@gmail.com>.
Again, it seems to me that you're implying Claus has problems with the
changes you did.
Reading his emails, I think the problems are more related to which branch /
when do the changes rather than if we do the changes.
On Mon, Sep 26, 2011 at 14:30, Christian Schneider
<ch...@die-schneider.net>wrote:
> I posted the basic ideas and goals of the refactorings in the Camel 3.0
> roadmap and also started discussions on DEV. One of the first is:
> http://camel.465427.n5.nabble.**com/Some-thoughts-about-the-**
> architecture-of-camel-**td3217183.html#a3218958<http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html#a3218958>
>
> The problem is that I could not already discuss the solution at that time.
> The dependencies in camel core were so confusing that it took me a lot of
> steps till the last pieces of refactorings needed to make the API self
> contained fell in place.
>
> So of course I could have done all that in my own branch but then we would
> have had zero discussions. That is just not the way Apache is supposed to
> work. Instead I did the work in the open with DEV discussions and Jira
> Tickets where everyone can take part. I also reacted to any concerns. Of
> course I do not always agree but I think I changed a lot of the refactorings
> based on your comments.
>
> Christian
>
>
> Am 26.09.2011 13:53, schrieb Claus Ibsen:
>
> On Mon, Sep 26, 2011 at 1:29 PM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>
>>> Am 26.09.2011 11:04, schrieb Claus Ibsen:
>>>
>>>> See the survey we did where people comment that they want the API
>>>> stable.
>>>> http://camel.apache.org/camel-**30-roadmap.html<http://camel.apache.org/camel-30-roadmap.html>(link on top of this page) We
>>>> have not recently put our a survey to ask for feedback in the community
>>>> if
>>>> they want bigger API changes in the 2.x, that will break backwards
>>>> compatibility.
>>>>
>>> Do you really dsitill the community will out of a single comment from the
>>> survey? I believe that there can be many people who want a stable API but
>>> the only reference I found in the survey was one single comment.
>>>
>>> The following five comments refer to keeping Camel stable: #16, #18,
>> #50, #57, and #58
>>
>> When I go to conferences and talk with existing Camel users, they all
>> say to keep Camel stable as is.
>> Some users who was using Camel 2.0 in its early days, refers to the
>> API changing a bit, and causing upgrades to become
>> harder, longer and to cost more man power and in the end more $$$.
>>
> The question is what people consider as stability. The API stability is
> only a part of that.
> From my own experience the stability problems in Camel almost never came
> from API changes. They mostly came from
> bugs. So since we have patch releases I am sure people will consider Camel
> to be much more stable.
>
> Btw. even a changed attribute in the file component is an "API" change for
> the user as it is the API he uses to access the
> file component. Disallowing such changes would stop the whole innovation
> though.
>
> I know it is a tough challenge to combine innovation and stability. On the
> long run though a well designed API and camel core will be the
> basis for a stable and flexible camel. Camel core has grown for much too
> long without a redesign. One example is all the wrapping that is done for
> interceptors, debugging, tracing, transaction. I assume that this happened
> partly because of the focus on stability but also partly because it was just
> too much effort to do a redesign for just a new feature. The result of this
> is declining quality. At first it is not really visible but I think we
> either are at a point or will soon be where innvation will slow down because
> of all the design issues.
>
>
> Christian
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I posted the basic ideas and goals of the refactorings in the Camel 3.0
roadmap and also started discussions on DEV. One of the first is:
http://camel.465427.n5.nabble.com/Some-thoughts-about-the-architecture-of-camel-td3217183.html#a3218958
The problem is that I could not already discuss the solution at that
time. The dependencies in camel core were so confusing that it took me a
lot of steps till the last pieces of refactorings needed to make the API
self contained fell in place.
So of course I could have done all that in my own branch but then we
would have had zero discussions. That is just not the way Apache is
supposed to work. Instead I did the work in the open with DEV
discussions and Jira Tickets where everyone can take part. I also
reacted to any concerns. Of course I do not always agree but I think I
changed a lot of the refactorings based on your comments.
Christian
Am 26.09.2011 13:53, schrieb Claus Ibsen:
> On Mon, Sep 26, 2011 at 1:29 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Am 26.09.2011 11:04, schrieb Claus Ibsen:
>>> See the survey we did where people comment that they want the API stable.
>>> http://camel.apache.org/camel-30-roadmap.html (link on top of this page) We
>>> have not recently put our a survey to ask for feedback in the community if
>>> they want bigger API changes in the 2.x, that will break backwards
>>> compatibility.
>> Do you really dsitill the community will out of a single comment from the
>> survey? I believe that there can be many people who want a stable API but
>> the only reference I found in the survey was one single comment.
>>
> The following five comments refer to keeping Camel stable: #16, #18,
> #50, #57, and #58
>
> When I go to conferences and talk with existing Camel users, they all
> say to keep Camel stable as is.
> Some users who was using Camel 2.0 in its early days, refers to the
> API changing a bit, and causing upgrades to become
> harder, longer and to cost more man power and in the end more $$$.
The question is what people consider as stability. The API stability is
only a part of that.
From my own experience the stability problems in Camel almost never
came from API changes. They mostly came from
bugs. So since we have patch releases I am sure people will consider
Camel to be much more stable.
Btw. even a changed attribute in the file component is an "API" change
for the user as it is the API he uses to access the
file component. Disallowing such changes would stop the whole innovation
though.
I know it is a tough challenge to combine innovation and stability. On
the long run though a well designed API and camel core will be the
basis for a stable and flexible camel. Camel core has grown for much too
long without a redesign. One example is all the wrapping that is done for
interceptors, debugging, tracing, transaction. I assume that this
happened partly because of the focus on stability but also partly
because it was just too much effort to do a redesign for just a new
feature. The result of this is declining quality. At first it is not
really visible but I think we either are at a point or will soon be
where innvation will slow down because of all the design issues.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 26, 2011 at 1:29 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Am 26.09.2011 11:04, schrieb Claus Ibsen:
>>
>> See the survey we did where people comment that they want the API stable.
>> http://camel.apache.org/camel-30-roadmap.html (link on top of this page) We
>> have not recently put our a survey to ask for feedback in the community if
>> they want bigger API changes in the 2.x, that will break backwards
>> compatibility.
>
> Do you really dsitill the community will out of a single comment from the
> survey? I believe that there can be many people who want a stable API but
> the only reference I found in the survey was one single comment.
>
The following five comments refer to keeping Camel stable: #16, #18,
#50, #57, and #58
When I go to conferences and talk with existing Camel users, they all
say to keep Camel stable as is.
Some users who was using Camel 2.0 in its early days, refers to the
API changing a bit, and causing upgrades to become
harder, longer and to cost more man power and in the end more $$$.
>> Neither have this been discussed in the @dev / among the entire Camel
>> team. Instead Christian just carried out doing this work as a "rouge soldier
>> on a mission". With no intend to stop. This is disrespectful for the
>> community, and for other Camel team members.
>
> I started some threads about possibly problematic changes. For any API
> breakage I also had an issues where mainly you commented a lot. I reacted on
> change requests. The more problematic changes I posted as patches first and
> committed as the dicussion showed an agreement. So please stop saying that I
> don´t discuss things.
>
You did not start any [DISCUSS] up front with the idea of your API changes.
You started creating a JIRA ticket to refactor the management code in
camel-core.
You did this, and disregarded backwards compatibility. When asked why,
you said it was on purpose.
Then you went on holiday. We restored the backwards compatibility,
which means end users can continue
using as is, or migrate to the new API as well. You can say we have
the best of both worlds now.
No API breakings, and there is a new API in place, that do not disrupt anything.
Then you continue focusing on the structure 101 diagrams and start
refactoring other parts of the core.
Instead it would have IMHO been better judgment from you, if you
posted on @dev a [DISCUSS] and gave amble time
for the entire Camel team to comment. Remember the team is big and
diverse. There are people like you and me, who
work on Camel on a daily basis. And then there is a majority of team
members who work on Camel from time to time.
Or only have time to work in their spare time. They are just as equal
part of the team, and should be given time to raise their feedback and
voice.
>> In the start of this year, when we talked about dropping support for JDK5
>> and Spring 2.x, we discussed this on @dev first.
>> http://camel.465427.n5.nabble.com/DISCUSS-Dropping-support-for-java-1-5-from-camel-2-7-0-onwards-td3354712.html
>> Then we had a vote. And we put out a message to the community ahead of time
>> http://camel.apache.org/2011/02/09/camel-270-drops-support-for-java-15.html
>> This time, none of this happened.
>
> The 2.9 release is not out. So we can still tell the community what to watch
> out for.
>
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 26.09.2011 11:04, schrieb Claus Ibsen:
> See the survey we did where people comment that they want the API
> stable. http://camel.apache.org/camel-30-roadmap.html (link on top of
> this page) We have not recently put our a survey to ask for feedback
> in the community if they want bigger API changes in the 2.x, that will
> break backwards compatibility.
Do you really dsitill the community will out of a single comment from
the survey? I believe that there can be many people who want a stable
API but the only reference I found in the survey was one single comment.
> Neither have this been discussed in the @dev / among the entire Camel
> team. Instead Christian just carried out doing this work as a "rouge
> soldier on a mission". With no intend to stop. This is disrespectful
> for the community, and for other Camel team members.
I started some threads about possibly problematic changes. For any API
breakage I also had an issues where mainly you commented a lot. I
reacted on change requests. The more problematic changes I posted as
patches first and committed as the dicussion showed an agreement. So
please stop saying that I don´t discuss things.
> In the start of this year, when we talked about dropping support for
> JDK5 and Spring 2.x, we discussed this on @dev first.
> http://camel.465427.n5.nabble.com/DISCUSS-Dropping-support-for-java-1-5-from-camel-2-7-0-onwards-td3354712.html
> Then we had a vote. And we put out a message to the community ahead of
> time
> http://camel.apache.org/2011/02/09/camel-270-drops-support-for-java-15.html
> This time, none of this happened.
The 2.9 release is not out. So we can still tell the community what to
watch out for.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 24, 2011 at 5:07 PM, Ioannis Canellos <io...@gmail.com> wrote:
> I understand that there are two respectable views on the subject:
>
> a) We should guarantee forward compatibility for 2.x as the major version
> implies.
> b) The API changes should not wait for the 3.0.0 release as its not going to
> happen any time soon.
>
> I was wondering if it would be possible to make a fast 3.0.0 release with
> the API changes and move the rest of 3.0.0 roadmap (which undoubtably will
> require more time) to release 4.0.0. The 3.x could have a short lifecycle
> and could serve till we are ready to deliver the rest of the roadmap into
> 4.0.0. Would such a solution make sense?
>
It does for me. Big API changes should happen in Camel 3.0 IMHO. And
leave the current 2.x API as is.
Then some "migration" APIs may be put in 2.x when the API in Camel 3.0
is settled. This can help people migrate gently.
Then you do not take the entire community as hostage by forcing the
API changes in Camel 2.x upon them.
This is very unexpected. We have not put out any message to the
community that this was going to happen.
The community have been using Camel 2.x for 2+ years and would expect
the API to be stable.
See the survey we did where people comment that they want the API stable.
http://camel.apache.org/camel-30-roadmap.html (link on top of this page)
We have not recently put our a survey to ask for feedback in the
community if they want bigger API changes in the 2.x,
that will break backwards compatibility.
Neither have this been discussed in the @dev / among the entire Camel team.
Instead Christian just carried out doing this work as a "rouge soldier
on a mission". With no intend to stop.
This is disrespectful for the community, and for other Camel team members.
In the start of this year, when we talked about dropping support for
JDK5 and Spring 2.x, we discussed this on @dev first.
http://camel.465427.n5.nabble.com/DISCUSS-Dropping-support-for-java-1-5-from-camel-2-7-0-onwards-td3354712.html
Then we had a vote. And we put out a message to the community ahead of time
http://camel.apache.org/2011/02/09/camel-270-drops-support-for-java-15.html
This time, none of this happened.
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> *
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Rob Davies <ra...@gmail.com>.
Nah - just get on with 3.0. Why would users want to migrate from 2.8.x to 2.9.x instead of waiting for 3.0 ? I don't see the rationale. We've have set the expectation for 3.0 for a while - http://camel.apache.org/camel-30-roadmap.html - there seems no benefit to our end users by dragging our feet.
On 25 Sep 2011, at 19:02, Hadrian Zbarcea wrote:
> Willem, it sounds to me like you agree on most of the issues, correct? Comments inline.
>
> Hadrian
>
>
>> I think already stated my +1 for a new API module to break the cycle
>> dependency of camel-core which was proposed by Christian.
> Excellent.
>
>> But I don't think we should ship the camel-api module in Camel 2.9, as
>> it break the user experience,
> Yes, no camel-api.jar in 2.9, camel-core stays the way it is.
>>
>> As you know there are lots of components which are not in the Apache
>> Camel repository. Any incompatible change in the camel core may cause
>> some trouble for the user when they upgrade to Camel 2.9.
> Yes, we strive for compatibility.
>
>> If we make the trunk as Camel 3.0, we can do more work than adding the
>> compatible classes, and we can keep on thinking to add the other great
>> feature of Camel3.0.
>>
>> The milestone release of Camel 3.0 could help us get the user feed back
>> and we did it in development of Camel 2.0 without any trouble.
> You are correct, but that's not what's being discussed. The question is when. The point was that a better time to start development for 3.0 is after 2.9 or possibly 2.10. Right now we do not know how 3.0 will look like. Starting development of 3.0 on trunk now and starting to figure out now what we want to do in 3.0 is disruptive and silly.
>
>> If we fork another branch for the Camel 2.9.0. We will have much work to
>> back port the patch. When we have some bug fix on the trunk, we have to
>> merge patch back to Camel 2.9.x, 2.8.x, 2.7.x three branches. That is
>> not a easy job to do.
> I suspect that once 2.9.0 is out we will stop active maintenance of 2.7.x and there will be at most one last release on 2.7.x. Iirc, we discussed to only provide community support for two past branches.
>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Willem, it sounds to me like you agree on most of the issues, correct?
Comments inline.
Hadrian
> I think already stated my +1 for a new API module to break the cycle
> dependency of camel-core which was proposed by Christian.
Excellent.
> But I don't think we should ship the camel-api module in Camel 2.9, as
> it break the user experience,
Yes, no camel-api.jar in 2.9, camel-core stays the way it is.
>
> As you know there are lots of components which are not in the Apache
> Camel repository. Any incompatible change in the camel core may cause
> some trouble for the user when they upgrade to Camel 2.9.
Yes, we strive for compatibility.
> If we make the trunk as Camel 3.0, we can do more work than adding the
> compatible classes, and we can keep on thinking to add the other great
> feature of Camel3.0.
>
> The milestone release of Camel 3.0 could help us get the user feed back
> and we did it in development of Camel 2.0 without any trouble.
You are correct, but that's not what's being discussed. The question is
when. The point was that a better time to start development for 3.0 is
after 2.9 or possibly 2.10. Right now we do not know how 3.0 will look
like. Starting development of 3.0 on trunk now and starting to figure
out now what we want to do in 3.0 is disruptive and silly.
> If we fork another branch for the Camel 2.9.0. We will have much work to
> back port the patch. When we have some bug fix on the trunk, we have to
> merge patch back to Camel 2.9.x, 2.8.x, 2.7.x three branches. That is
> not a easy job to do.
I suspect that once 2.9.0 is out we will stop active maintenance of
2.7.x and there will be at most one last release on 2.7.x. Iirc, we
discussed to only provide community support for two past branches.
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Willem Jiang <wi...@gmail.com>.
On 9/25/11 9:14 AM, Hadrian Zbarcea wrote:
> Ioannis, what you suggest is similar to what Christian was suggesting
> except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
> calling these versions 3.0, 3.1, with the intention, probably, to
> accommodate Claus' proposal.
>
> Now, to answer Willem and Rob other messages in this thread too, let's
> take another look at Claus' proposal. It states:
> <quote>
> 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.
> </quote>
>
> 1) not quite clear, I assume he means to allow more freedom in making
> incompatible changes. I think this extra freedom is not that necessary
> now, we should not introduce significant incompatibilities
> 2) Sure, we can keep doing it on 2.x, not worse than it was in all minor
> versions until now.
> 3) Well, it does
> 4) So?
> 5) Really? Where's that coming from?
>
Take it easy,
> In general the expectation from a major release is to come with, well,
> major improvements in architecture, api, functionality, etc, and yes, a
> major release may not necessarily be fully backwards compatible. See
> [1], [2] and other references on the web.
>
> From what I understand, Christian is not proposing nor making
> significant improvements in the api, he's simply cleaning it up and
> reducing tangles, circular dependencies that are a symptom of bad
> design. This would pave the way for an improved api in 3.0.
I think already stated my +1 for a new API module to break the cycle
dependency of camel-core which was proposed by Christian.
But I don't think we should ship the camel-api module in Camel 2.9, as
it break the user experience,
As you know there are lots of components which are not in the Apache
Camel repository. Any incompatible change in the camel core may cause
some trouble for the user when they upgrade to Camel 2.9.
If we make the trunk as Camel 3.0, we can do more work than adding the
compatible classes, and we can keep on thinking to add the other great
feature of Camel3.0.
The milestone release of Camel 3.0 could help us get the user feed back
and we did it in development of Camel 2.0 without any trouble.
If we fork another branch for the Camel 2.9.0. We will have much work to
back port the patch. When we have some bug fix on the trunk, we have
to merge patch back to Camel 2.9.x, 2.8.x, 2.7.x three branches. That is
not a easy job to do.
>
> What should be done in 3.0, at least imho, and hopefully we'll get to
> the point to talk more seriously about that:
> * cleanup the api an architecture to allow one to use camel as an
> integration framework *without* the routing part. For instance one
> should be able to use just a producer template and the components of
> choice with a lean runtime (without the dsl, some processors maybe,
> support for routing, etc)
> * it should be lean enough to run well on mobile devices
> * the threading model should be significantly improved
> * better support for tools
> * better support for clustering
> * other tactical goals like reducing the build/test time to under 1 hour
> (we made significant improvements there already, but there's still a lot
> more to do); this is one area that frustrates me a lot.
> * significant improvements in the test kit, components for instance
> should not be unit tested using routes and RouteBuilders. Instead we
> should test/assert that configuration is used as expected (positive and
> negative tests), messages are produced and consumed as expected, proper
> types and headers are used/set, etc.
> * ... and many more that we'll discuss in due time.
>
> Now, these kind of changes may introduce some incompatibilities and
> would warrant a 3.0, but just the changes Christian made? Seriously?
> Most of the above are not only my ideas, and not new, they were
> discussed by different committers and users over time. I don't think we
> are yet ready to fully shape a camel-3.0, and the goal is to make steps
> in that direction and get ready for it.
>
Can you put them into the road map of camel 3.0[1], I saw Claus and
Christian updated most entry of them. We could keep track of it in the
wiki in case we forget them.
[1]http://camel.apache.org/camel-30-roadmap.html
> Hadrian
>
>
> [1] http://en.wikipedia.org/wiki/Software_versioning
> [2] http://dictionary.reference.com/browse/major+release
>
>
> On 09/24/2011 11:07 AM, Ioannis Canellos wrote:
>> I understand that there are two respectable views on the subject:
>>
>> a) We should guarantee forward compatibility for 2.x as the major version
>> implies.
>> b) The API changes should not wait for the 3.0.0 release as its not
>> going to
>> happen any time soon.
>>
>> I was wondering if it would be possible to make a fast 3.0.0 release with
>> the API changes and move the rest of 3.0.0 roadmap (which undoubtably
>> will
>> require more time) to release 4.0.0. The 3.x could have a short lifecycle
>> and could serve till we are ready to deliver the rest of the roadmap into
>> 4.0.0. Would such a solution make sense?
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Donald, you are mostly correct, this would require mostly repackaging of
the jars, i.e. splitting the core into multiple jars. We will probably
have to do something with the CamelContext, it became a bit of a
hodge-podge. In any case, the intent is for the migration to be still
simple and straightforward. The mantra of Camel is to make integration
*simple*.
Most of the API is great but it gained a lot of extra fat not really
used by users. There are a few other issues. I don't want to say more
about this now, simply because my crystal ball is blurry and it'll take
quite a few discussions on dev@ to sort this out. So stay tuned and
remember that your feedback is appreciated, pitch in and don't be shy
(well, Donald, you sent this one, looks like you're not :), so guys,
follow Donald's example). Your success and mental health is important to
us, we'll try to not go overboard.
Cheers,
Hadrian
On 09/24/2011 09:31 PM, Donald Whytock wrote:
> On Sat, Sep 24, 2011 at 9:14 PM, Hadrian Zbarcea<hz...@gmail.com> wrote:
>> * cleanup the api an architecture to allow one to use camel as an
>> integration framework *without* the routing part. For instance one should be
>> able to use just a producer template and the components of choice with a
>> lean runtime (without the dsl, some processors maybe, support for routing,
>> etc)
>
> +1 on this one...let Camel be a protocol repository. Possibly also
> allowing an endpoint to act as a simple readable BlockingQueue.
>
> Though this wouldn't necessarily be a compatibility problem, would it?
> Could it not be done as a new layer under the routing, leaving the
> existing API intact?
>
> Don
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Donald Whytock <dw...@gmail.com>.
On Sat, Sep 24, 2011 at 9:14 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> * cleanup the api an architecture to allow one to use camel as an
> integration framework *without* the routing part. For instance one should be
> able to use just a producer template and the components of choice with a
> lean runtime (without the dsl, some processors maybe, support for routing,
> etc)
+1 on this one...let Camel be a protocol repository. Possibly also
allowing an endpoint to act as a simple readable BlockingQueue.
Though this wouldn't necessarily be a compatibility problem, would it?
Could it not be done as a new layer under the routing, leaving the
existing API intact?
Don
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Ioannis, what you suggest is similar to what Christian was suggesting
except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
calling these versions 3.0, 3.1, with the intention, probably, to
accommodate Claus' proposal.
Now, to answer Willem and Rob other messages in this thread too, let's
take another look at Claus' proposal. It states:
<quote>
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.
</quote>
1) not quite clear, I assume he means to allow more freedom in making
incompatible changes. I think this extra freedom is not that necessary
now, we should not introduce significant incompatibilities
2) Sure, we can keep doing it on 2.x, not worse than it was in all minor
versions until now.
3) Well, it does
4) So?
5) Really? Where's that coming from?
In general the expectation from a major release is to come with, well,
major improvements in architecture, api, functionality, etc, and yes, a
major release may not necessarily be fully backwards compatible. See
[1], [2] and other references on the web.
From what I understand, Christian is not proposing nor making
significant improvements in the api, he's simply cleaning it up and
reducing tangles, circular dependencies that are a symptom of bad
design. This would pave the way for an improved api in 3.0.
What should be done in 3.0, at least imho, and hopefully we'll get to
the point to talk more seriously about that:
* cleanup the api an architecture to allow one to use camel as an
integration framework *without* the routing part. For instance one
should be able to use just a producer template and the components of
choice with a lean runtime (without the dsl, some processors maybe,
support for routing, etc)
* it should be lean enough to run well on mobile devices
* the threading model should be significantly improved
* better support for tools
* better support for clustering
* other tactical goals like reducing the build/test time to under 1 hour
(we made significant improvements there already, but there's still a lot
more to do); this is one area that frustrates me a lot.
* significant improvements in the test kit, components for instance
should not be unit tested using routes and RouteBuilders. Instead we
should test/assert that configuration is used as expected (positive and
negative tests), messages are produced and consumed as expected, proper
types and headers are used/set, etc.
* ... and many more that we'll discuss in due time.
Now, these kind of changes may introduce some incompatibilities and
would warrant a 3.0, but just the changes Christian made? Seriously?
Most of the above are not only my ideas, and not new, they were
discussed by different committers and users over time. I don't think we
are yet ready to fully shape a camel-3.0, and the goal is to make steps
in that direction and get ready for it.
Hadrian
[1] http://en.wikipedia.org/wiki/Software_versioning
[2] http://dictionary.reference.com/browse/major+release
On 09/24/2011 11:07 AM, Ioannis Canellos wrote:
> I understand that there are two respectable views on the subject:
>
> a) We should guarantee forward compatibility for 2.x as the major version
> implies.
> b) The API changes should not wait for the 3.0.0 release as its not going to
> happen any time soon.
>
> I was wondering if it would be possible to make a fast 3.0.0 release with
> the API changes and move the rest of 3.0.0 roadmap (which undoubtably will
> require more time) to release 4.0.0. The 3.x could have a short lifecycle
> and could serve till we are ready to deliver the rest of the roadmap into
> 4.0.0. Would such a solution make sense?
>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Ioannis Canellos <io...@gmail.com>.
I understand that there are two respectable views on the subject:
a) We should guarantee forward compatibility for 2.x as the major version
implies.
b) The API changes should not wait for the 3.0.0 release as its not going to
happen any time soon.
I was wondering if it would be possible to make a fast 3.0.0 release with
the API changes and move the rest of 3.0.0 roadmap (which undoubtably will
require more time) to release 4.0.0. The 3.x could have a short lifecycle
and could serve till we are ready to deliver the rest of the roadmap into
4.0.0. Would such a solution make sense?
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
*
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Willem Jiang <wi...@gmail.com>.
If you take a look at the Jetty[1] or Spring[2], they are doing the
milestone release for the big version release.
I guess there is no big user to use that kind of milestone release in
production, but it tells the user we are moving forward, if you take
some time to try it , you will not spend lots of time to migration when
the final stable release is out.
And the mile stone release can get lots of useful feed back and we can
keep pushing it to the GA release.
If we don't make a trunk as Camel 3.0, we will never get Camel 3.0 out
:)
[1]http://www.eclipse.org/projects/project-plan.php?projectid=rt.jetty
[2]http://static.springsource.org/spring/docs/3.0.x/changelog.txt
On Sat Sep 24 21:48:08 2011, Hadrian Zbarcea wrote:
> I don't think we're debating if, we're debating when. I get your point
> and I would agree if this was any different than before. The reality
> though is that *every* single minor release of Camel was *not* 100%
> backwards compatible. We absolutely strive for backward compatibility
> and 2.9.0 should not be worse. We should be 100% compatible in patch
> releases though.
>
> The reality is that when we'll start working on 3.x we won't have it
> for at least 9 months, most likely. Nobody will migrate to a 3.0-Mx
> milestone release. It's also likely that many won't migrate to a new
> 2.x while we actively work on 3.x. In the patch releases we only have
> a small subset of the new features on trunk.
>
> I know some are kinda tired of 2.x and want to look at and talk about
> the next great thing. We had this discussion a year ago and promises
> were made that 3.0 will be out in Q1 2011. We don't yet know how 3.0
> will look like, although many have their ideas. We know that we want a
> cleaner api, we know we want it leaner and we know that we want
> shorter build times and other few things. We can easily continue to
> work on that and the other features that come with every release until
> we figure out how 3.0 will look like. Doing it now is, imho, a
> distraction.
>
> My $0.02,
> Hadrian
>
>
>
> On 09/24/2011 08:18 AM, Hiram Chirino wrote:
>> The fact that it's not 100% compatible IS why it's not a good idea to
>> call it 2.x. The point of version numbering schemes are to reflect
>> the compatibility between releases. If trunk is not a major release,
>> I don't know what is. And yes I would hope that the 3.x line tries to
>> keep as much backward compatible support with 2.x as possible.
>> Otherwise, you've got a brand new product in your hands and your 2.x
>> users will have a big wall to climb to to upgrade to the 3.x. As for
>> dropping deprecated APIs, I'd do that in a 3.1 or once we verify that
>> migration to 3.x is fully backward compatible from 2.x (I'm sure we
>> will miss some compatibility stuff in the first few releases of 3.x).
>>
>>
>> Regards,
>> Hiram
>>
>> FuseSource
>> Web: http://fusesource.com/
>>
>>
>>
>>
>> On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>> I just talked to Dan and Hadrian about this idea. The problem is that
>>> however we would call such a release people would take it as kind of a
>>> milestone and it would probably not be used much.
>>>
>>> So it is probably better to use the 2.9 and perhaps 2.10 release for
>>> that.
>>> The 2.x naming will suggest that it is mostly compatible and we can
>>> mention
>>> in the release not that it is not 100% compatbile.
>>>
>>> For people who do not want the changes we can use the 2.8.x branch.
>>> So we
>>> could keep porting back some improvements like Dan did for people
>>> who want
>>> to stay 100% compatible.
>>>
>>> Christian
>>>
>>>
>>> Am 23.09.2011 16:43, schrieb Christian Schneider:
>>>>
>>>> Basically that is a good idea. I also thought about a similar
>>>> solution. I
>>>> would only not like to call it milestone as that typically implies
>>>> that it
>>>> is instable. No sane admin will deploy a milestone release in
>>>> production.
>>>> How about 3.0.0-compat or similar. So we could have one or more
>>>> releases
>>>> of this that are fully production ready but will still contain the
>>>> @Deprecated classes. Then we can release Camel 3.0.0 that simply
>>>> removes
>>>> these.
>>>>
>>>> Christian
>>>>
>>>> Am 23.09.2011 15:59, schrieb Willem Jiang:
>>>>>
>>>>> 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 ?
>>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Sep 24, 2011 at 3:48 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I don't think we're debating if, we're debating when. I get your point and I
> would agree if this was any different than before. The reality though is
> that *every* single minor release of Camel was *not* 100% backwards
> compatible. We absolutely strive for backward compatibility and 2.9.0 should
> not be worse. We should be 100% compatible in patch releases though.
>
The previous minor releases of Camel could have API changes, but they
would be at a very minimal,
and not touch key areas in camel-core.
This is not the case on Camel 2.9, and the JIRA tickets that Christian
have assigned to himself.
In fact the remainder of those tickets is suggesting big API breakings
in the SPI / model packages.
Likewise Hadrian committed a change to Component / Endpoint API which
will break API for people.
Those API changes have *not* been documented in the release notes,
likewise many of the changes done by Christian.
Last year we did a survey to ask for feedback, and we said the survey
is to be used for Camel 3.0 planning.
See this page, and link to survey in top
http://camel.apache.org/camel-30-roadmap.html
If you look in the comments in the survey, at the end, then people in
the community, is asking for *NOT* to change the API
in minor releases.
> The reality is that when we'll start working on 3.x we won't have it for at
> least 9 months, most likely. Nobody will migrate to a 3.0-Mx milestone
> release. It's also likely that many won't migrate to a new 2.x while we
> actively work on 3.x. In the patch releases we only have a small subset of
> the new features on trunk.
>
> I know some are kinda tired of 2.x and want to look at and talk about the
> next great thing. We had this discussion a year ago and promises were made
> that 3.0 will be out in Q1 2011. We don't yet know how 3.0 will look like,
> although many have their ideas. We know that we want a cleaner api, we know
> we want it leaner and we know that we want shorter build times and other few
> things. We can easily continue to work on that and the other features that
> come with every release until we figure out how 3.0 will look like. Doing it
> now is, imho, a distraction.
>
We already know what Camel 3.0 will look like. We have a roadmap up
for 1 year or longer.
http://camel.apache.org/camel-30-roadmap.html
There is no rule, that says a developing Camel 3.0 should take 9+
months. In fact we have previously
talked about doing a quick Camel 3.0 release with API changes, and
internal routing engine optimizations/cleanup as primary goals.
There is no rule that says Camel 3.0 has to be a total re-architecture
and it must have 100+ new features and whatnot.
> My $0.02,
> Hadrian
>
>
>
> On 09/24/2011 08:18 AM, Hiram Chirino wrote:
>>
>> The fact that it's not 100% compatible IS why it's not a good idea to
>> call it 2.x. The point of version numbering schemes are to reflect
>> the compatibility between releases. If trunk is not a major release,
>> I don't know what is. And yes I would hope that the 3.x line tries to
>> keep as much backward compatible support with 2.x as possible.
>> Otherwise, you've got a brand new product in your hands and your 2.x
>> users will have a big wall to climb to to upgrade to the 3.x. As for
>> dropping deprecated APIs, I'd do that in a 3.1 or once we verify that
>> migration to 3.x is fully backward compatible from 2.x (I'm sure we
>> will miss some compatibility stuff in the first few releases of 3.x).
>>
>>
>> Regards,
>> Hiram
>>
>> FuseSource
>> Web: http://fusesource.com/
>>
>>
>>
>>
>> On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>>
>>> I just talked to Dan and Hadrian about this idea. The problem is that
>>> however we would call such a release people would take it as kind of a
>>> milestone and it would probably not be used much.
>>>
>>> So it is probably better to use the 2.9 and perhaps 2.10 release for
>>> that.
>>> The 2.x naming will suggest that it is mostly compatible and we can
>>> mention
>>> in the release not that it is not 100% compatbile.
>>>
>>> For people who do not want the changes we can use the 2.8.x branch. So we
>>> could keep porting back some improvements like Dan did for people who
>>> want
>>> to stay 100% compatible.
>>>
>>> Christian
>>>
>>>
>>> Am 23.09.2011 16:43, schrieb Christian Schneider:
>>>>
>>>> Basically that is a good idea. I also thought about a similar solution.
>>>> I
>>>> would only not like to call it milestone as that typically implies that
>>>> it
>>>> is instable. No sane admin will deploy a milestone release in
>>>> production.
>>>> How about 3.0.0-compat or similar. So we could have one or more releases
>>>> of this that are fully production ready but will still contain the
>>>> @Deprecated classes. Then we can release Camel 3.0.0 that simply removes
>>>> these.
>>>>
>>>> Christian
>>>>
>>>> Am 23.09.2011 15:59, schrieb Willem Jiang:
>>>>>
>>>>> 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 ?
>>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I don't think we're debating if, we're debating when. I get your point
and I would agree if this was any different than before. The reality
though is that *every* single minor release of Camel was *not* 100%
backwards compatible. We absolutely strive for backward compatibility
and 2.9.0 should not be worse. We should be 100% compatible in patch
releases though.
The reality is that when we'll start working on 3.x we won't have it for
at least 9 months, most likely. Nobody will migrate to a 3.0-Mx
milestone release. It's also likely that many won't migrate to a new 2.x
while we actively work on 3.x. In the patch releases we only have a
small subset of the new features on trunk.
I know some are kinda tired of 2.x and want to look at and talk about
the next great thing. We had this discussion a year ago and promises
were made that 3.0 will be out in Q1 2011. We don't yet know how 3.0
will look like, although many have their ideas. We know that we want a
cleaner api, we know we want it leaner and we know that we want shorter
build times and other few things. We can easily continue to work on that
and the other features that come with every release until we figure out
how 3.0 will look like. Doing it now is, imho, a distraction.
My $0.02,
Hadrian
On 09/24/2011 08:18 AM, Hiram Chirino wrote:
> The fact that it's not 100% compatible IS why it's not a good idea to
> call it 2.x. The point of version numbering schemes are to reflect
> the compatibility between releases. If trunk is not a major release,
> I don't know what is. And yes I would hope that the 3.x line tries to
> keep as much backward compatible support with 2.x as possible.
> Otherwise, you've got a brand new product in your hands and your 2.x
> users will have a big wall to climb to to upgrade to the 3.x. As for
> dropping deprecated APIs, I'd do that in a 3.1 or once we verify that
> migration to 3.x is fully backward compatible from 2.x (I'm sure we
> will miss some compatibility stuff in the first few releases of 3.x).
>
>
> Regards,
> Hiram
>
> FuseSource
> Web: http://fusesource.com/
>
>
>
>
> On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> I just talked to Dan and Hadrian about this idea. The problem is that
>> however we would call such a release people would take it as kind of a
>> milestone and it would probably not be used much.
>>
>> So it is probably better to use the 2.9 and perhaps 2.10 release for that.
>> The 2.x naming will suggest that it is mostly compatible and we can mention
>> in the release not that it is not 100% compatbile.
>>
>> For people who do not want the changes we can use the 2.8.x branch. So we
>> could keep porting back some improvements like Dan did for people who want
>> to stay 100% compatible.
>>
>> Christian
>>
>>
>> Am 23.09.2011 16:43, schrieb Christian Schneider:
>>>
>>> Basically that is a good idea. I also thought about a similar solution. I
>>> would only not like to call it milestone as that typically implies that it
>>> is instable. No sane admin will deploy a milestone release in production.
>>> How about 3.0.0-compat or similar. So we could have one or more releases
>>> of this that are fully production ready but will still contain the
>>> @Deprecated classes. Then we can release Camel 3.0.0 that simply removes
>>> these.
>>>
>>> Christian
>>>
>>> Am 23.09.2011 15:59, schrieb Willem Jiang:
>>>>
>>>> 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 ?
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hiram Chirino <hi...@hiramchirino.com>.
The fact that it's not 100% compatible IS why it's not a good idea to
call it 2.x. The point of version numbering schemes are to reflect
the compatibility between releases. If trunk is not a major release,
I don't know what is. And yes I would hope that the 3.x line tries to
keep as much backward compatible support with 2.x as possible.
Otherwise, you've got a brand new product in your hands and your 2.x
users will have a big wall to climb to to upgrade to the 3.x. As for
dropping deprecated APIs, I'd do that in a 3.1 or once we verify that
migration to 3.x is fully backward compatible from 2.x (I'm sure we
will miss some compatibility stuff in the first few releases of 3.x).
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I just talked to Dan and Hadrian about this idea. The problem is that
> however we would call such a release people would take it as kind of a
> milestone and it would probably not be used much.
>
> So it is probably better to use the 2.9 and perhaps 2.10 release for that.
> The 2.x naming will suggest that it is mostly compatible and we can mention
> in the release not that it is not 100% compatbile.
>
> For people who do not want the changes we can use the 2.8.x branch. So we
> could keep porting back some improvements like Dan did for people who want
> to stay 100% compatible.
>
> Christian
>
>
> Am 23.09.2011 16:43, schrieb Christian Schneider:
>>
>> Basically that is a good idea. I also thought about a similar solution. I
>> would only not like to call it milestone as that typically implies that it
>> is instable. No sane admin will deploy a milestone release in production.
>> How about 3.0.0-compat or similar. So we could have one or more releases
>> of this that are fully production ready but will still contain the
>> @Deprecated classes. Then we can release Camel 3.0.0 that simply removes
>> these.
>>
>> Christian
>>
>> Am 23.09.2011 15:59, schrieb Willem Jiang:
>>>
>>> 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 ?
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I just talked to Dan and Hadrian about this idea. The problem is that
however we would call such a release people would take it as kind of a
milestone and it would probably not be used much.
So it is probably better to use the 2.9 and perhaps 2.10 release for
that. The 2.x naming will suggest that it is mostly compatible and we
can mention in the release not that it is not 100% compatbile.
For people who do not want the changes we can use the 2.8.x branch. So
we could keep porting back some improvements like Dan did for people who
want to stay 100% compatible.
Christian
Am 23.09.2011 16:43, schrieb Christian Schneider:
> Basically that is a good idea. I also thought about a similar
> solution. I would only not like to call it milestone as that typically
> implies that it is instable. No sane admin will deploy a milestone
> release in production.
> How about 3.0.0-compat or similar. So we could have one or more
> releases of this that are fully production ready but will still
> contain the @Deprecated classes. Then we can release Camel 3.0.0 that
> simply removes these.
>
> Christian
>
> Am 23.09.2011 15:59, schrieb Willem Jiang:
>> 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 ?
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
Basically that is a good idea. I also thought about a similar solution.
I would only not like to call it milestone as that typically implies
that it is instable. No sane admin will deploy a milestone release in
production.
How about 3.0.0-compat or similar. So we could have one or more releases
of this that are fully production ready but will still contain the
@Deprecated classes. Then we can release Camel 3.0.0 that simply removes
these.
Christian
Am 23.09.2011 15:59, schrieb Willem Jiang:
> 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 ?
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Willem Jiang <wi...@gmail.com>.
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:
> - https://issues.apache.org/jira/browse/CAMEL-4475
> - https://issues.apache.org/jira/browse/CAMEL-4417
>
> 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
>> <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
>>>
>>>
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
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:
- https://issues.apache.org/jira/browse/CAMEL-4475
- https://issues.apache.org/jira/browse/CAMEL-4417
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
> <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
>>
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Willem Jiang <wi...@gmail.com>.
I think we can spend 6~9 month to do the Camel 3.0 mile stone release.
In this way we can provide user enough time to do the migration.
Camel 2.8.x can be our 2.x maintenance branch for a lot time :)
On 9/23/11 9:11 PM, Hadrian Zbarcea wrote:
> -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
>>>
>>>
>>
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Hadrian Zbarcea <hz...@gmail.com>.
-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
>>
>>
>
>
>
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Claus Ibsen <cl...@gmail.com>.
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
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [DISCUSS] - Trunk as Camel 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
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