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/05 16:04:15 UTC
[DISCUSS] - API stability in Camel 2.x
Hi
I am writing this mail with a "community hat" as well being a very
concerned Camel team member.
The API in camel-core had a fair number of changes recently, which is
a strong concern from a community point of view.
Basically the community views Camel 2.x as an mature and well
established project, but also an "old and stable" product because of
Camel 2.x being 2+ years old.
In summary the community wants in Camel 2.x
- NO CHANGES IN API
The community do not care if class is named X or placed in Y etc. The
community care about that the class is kept named X and kept placed in
Y.
That said, API changes is needed from time to time, and this is why
you accumulate API change ideas in roadmap wiki pages, TODO in the
source code etc. And possible some JIRA tickets.
Then when a new major version is in the works such as Camel 3.0, then
those API changes can be executed.
In fact designing an API is a bigger challenge than at first thought.
Today you feel class X should be named and placed in Y package. To
days later it should be named X2 and placed in Z package instead. To
give amble time for API changes to settled down, and see how it "works
out" then milestone releases of the 3.0 is being released. This gives
the community and early adopters a changes to help out and give
feedback. This is common practice and how other projects do.
The Apache Camel 2.x project is a very successful project and its
usage have reached beyond what you may see as a typical situation. We
have many other open source projects which integrate directly with
Camel in their products. We have other open source projects and
commercial products that is based on top of Camel, or using Camel
heavily internally. Their most likely use
the API in ways the typical end user does not. So bottom line the
exposed API is in use out there.
The Camel team ove to the community to keep the API stable regardless
if a class could be renamed to X to have a bit better name etc.
Likewise it does not give confort in the community if the API is kept
changing and their use of the API keeps being @deprecated.
So when they compile or upgrade to a new version, they get scared
because of the sheer number of @deprecate warnings.
It is a costly $$$ for any organization to change source code, as
often rigors testing and procedures kicks in, when the source code
must be changed.
Likewise the Apache Camel subversion repository on trunk, is not a
personal * experiment* branch where the Camel committers should "play"
and move around with classes and whatnot. It would be better to setup
a branch or a personal project on github etc to work on the expriment
(for example as I did with the simple language improvements project).
>From community point of view. Keep the API stable in our "old" and
beloved Camel 2.x product.
>From community point of view. Start a discussion about Camel 3.0, as
we think the Camel 2.x product is "old and stable".
But the community would like a brand new Camel 3.0 in early 2012.
--
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] - API stability in Camel 2.x
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Björn,
Yes, that is the plan, the current thinking is that n=2. That means that
we intend to actively support 2 past releases. It also means that a
given minor release will be supported for about a year. We didn't
formalize this, and it's not easy do to so, but that's the intent.
We are now in the process of doing major cleanup in preparation to the
camel-3.0 release, while staying backwards compatible as much as
possible with the 2.x versions. One of the intended consequences,
besides cleaning up the architecture, improving performance and
scalability and simplifying development is bringing down the build time.
This would go a long way towards making it possible to maintain older
branches, as build times right now are kinda prohibitive. We already
made major progress.
You are right about the bumpy road, and we are making major efforts to
smoothen it out.
Cheers,
Hadrian
On 09/09/2011 07:34 AM, Björn Bength wrote:
> The definition of "as many versions as possible" must of course be decided.
> But ought to be greater than 0 (zero).
>
> Backporting and patch-releasing bug fixes are already done today by,
> for instance, fusesource and yourself earlier.
> To add value for their customers.
> However, I think some attention on the Apache bug fix releases is, in
> the longer run, necesseray.
> Of course it requires resources, that often is busy full time with
> their own customer's projects.
> The full steam ahead on trunk has been impressive though, but it's
> been a bumpy road :-)
>
> regards
> björn
>
>
> On Fri, Sep 9, 2011 at 11:43 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Yes absolutely bug fix releases are key to stability and give us more
>> freedom to do changes in minor releases.
>>
>> Until last year I was responsible for the internal camel and cxf
>> distributions at a germany energy company.
>>
>> CXF could normally be used as is. If there were any bugs then typically the
>> next bugfix release had them fixed.
>>
>> For camel I almost always had to maintain an internal bugfix release. As
>> camel only had minor versions every version contained the fixes but also a
>> lot of changes.
>> With these changes we often hist another issue again that prevented us from
>> rolling it out. So I ended up with taking the patches for the issues that
>> were important for us and
>> compiled my own bugfix release from the minor release we used. That worked
>> really well. As camel now supports bugfix releases I guess most times this
>> will not be necessary anymore for users.
>>
>> I do not think backporting to as many versions as possible is a good idea
>> though. Typically having one or two maintained older version should be ok
>> for most occasions. That is because porting to older
>> versions is tpyically increasingly more work and every version to maintain
>> is generally a lot of additional work.
>>
>> On the other hand we could have releases for older versions that are
>> requested by paying users of the companies that support camel development.
>> So this long term support could be a way for these companies to get support
>> contracts but still
>> having the results in the open as camel releases.
>>
>> Christian
>>
>>
>> Am 09.09.2011 11:21, schrieb Björn Bength:
>>>
>>> Hi,
>>>
>>> This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
>>> 2.8.1 etc
>>> and make an effort to back port important bug fixes to as many
>>> "stable" camel versions as possible.
>>> Then I think slight api changes is more tolerable to end users.
>>>
>>> Björn
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Björn Bength <bj...@gmail.com>.
The definition of "as many versions as possible" must of course be decided.
But ought to be greater than 0 (zero).
Backporting and patch-releasing bug fixes are already done today by,
for instance, fusesource and yourself earlier.
To add value for their customers.
However, I think some attention on the Apache bug fix releases is, in
the longer run, necesseray.
Of course it requires resources, that often is busy full time with
their own customer's projects.
The full steam ahead on trunk has been impressive though, but it's
been a bumpy road :-)
regards
björn
On Fri, Sep 9, 2011 at 11:43 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Yes absolutely bug fix releases are key to stability and give us more
> freedom to do changes in minor releases.
>
> Until last year I was responsible for the internal camel and cxf
> distributions at a germany energy company.
>
> CXF could normally be used as is. If there were any bugs then typically the
> next bugfix release had them fixed.
>
> For camel I almost always had to maintain an internal bugfix release. As
> camel only had minor versions every version contained the fixes but also a
> lot of changes.
> With these changes we often hist another issue again that prevented us from
> rolling it out. So I ended up with taking the patches for the issues that
> were important for us and
> compiled my own bugfix release from the minor release we used. That worked
> really well. As camel now supports bugfix releases I guess most times this
> will not be necessary anymore for users.
>
> I do not think backporting to as many versions as possible is a good idea
> though. Typically having one or two maintained older version should be ok
> for most occasions. That is because porting to older
> versions is tpyically increasingly more work and every version to maintain
> is generally a lot of additional work.
>
> On the other hand we could have releases for older versions that are
> requested by paying users of the companies that support camel development.
> So this long term support could be a way for these companies to get support
> contracts but still
> having the results in the open as camel releases.
>
> Christian
>
>
> Am 09.09.2011 11:21, schrieb Björn Bength:
>>
>> Hi,
>>
>> This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
>> 2.8.1 etc
>> and make an effort to back port important bug fixes to as many
>> "stable" camel versions as possible.
>> Then I think slight api changes is more tolerable to end users.
>>
>> Björn
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Yes absolutely bug fix releases are key to stability and give us more
freedom to do changes in minor releases.
Until last year I was responsible for the internal camel and cxf
distributions at a germany energy company.
CXF could normally be used as is. If there were any bugs then typically
the next bugfix release had them fixed.
For camel I almost always had to maintain an internal bugfix release. As
camel only had minor versions every version contained the fixes but also
a lot of changes.
With these changes we often hist another issue again that prevented us
from rolling it out. So I ended up with taking the patches for the
issues that were important for us and
compiled my own bugfix release from the minor release we used. That
worked really well. As camel now supports bugfix releases I guess most
times this will not be necessary anymore for users.
I do not think backporting to as many versions as possible is a good
idea though. Typically having one or two maintained older version should
be ok for most occasions. That is because porting to older
versions is tpyically increasingly more work and every version to
maintain is generally a lot of additional work.
On the other hand we could have releases for older versions that are
requested by paying users of the companies that support camel
development. So this long term support could be a way for these
companies to get support contracts but still
having the results in the open as camel releases.
Christian
Am 09.09.2011 11:21, schrieb Björn Bength:
> Hi,
>
> This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
> 2.8.1 etc
> and make an effort to back port important bug fixes to as many
> "stable" camel versions as possible.
> Then I think slight api changes is more tolerable to end users.
>
> Björn
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Willem Jiang <wi...@gmail.com>.
You can't just use the merge tool back port the bug fix to the other
branch if the API is changed lots.
Every fix on the different branch is almost a rewrite.
As we don't have much resource to maintain more than three branch, we
still need to let the big API change happen in Camel 3.x.
On Fri Sep 9 17:21:47 2011, Björn Bength wrote:
> Hi,
>
> This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
> 2.8.1 etc
> and make an effort to back port important bug fixes to as many
> "stable" camel versions as possible.
> Then I think slight api changes is more tolerable to end users.
>
> Björn
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Björn Bength <bj...@gmail.com>.
Hi,
This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
2.8.1 etc
and make an effort to back port important bug fixes to as many
"stable" camel versions as possible.
Then I think slight api changes is more tolerable to end users.
Björn
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 8, 2011 at 1:31 PM, Rob Davies <ra...@gmail.com> wrote:
> Mmm - seems still to be there (on SendDefinition). I'm deriving a class from WireTapDefinition - which can no longer find getUriOrRef() moving from camel 2.7 to 2.8 :)
>
> On 8 Sep 2011, at 11:59, Rob Davies wrote:
>
>> getUriOrRef() was removed from ProcessDefinition between Camel 2.7 and Camel 2.8 (not even deprecated) - what's the thinking behind that ?
>>
Thet getUriOrRef() method is on SendDefinition, not on
ProcessDefinition. The method hasn't been removed, its frankly because
WireTapDefinition has changed. See a bit below.
The 2.8 release notes documents the model and API changes
http://camel.apache.org/camel-280-release.html
So the WireTapDefinition no long extend SendDefinition. Reasons are
two fold. It was improved to support new uses-cases asked by the
community. Also we had a look at the XSD from the model and found some
mismatches. In particular because 3rd party tooling and the likes did
surface some issues in the XSD, which end users did not discover when
they create Camel routes in XML. So we cleaned up those mistakes in
the 2.8 release. And we added a special DSL changes section to the
release notes.
>> thanks,
>>
>> Rob
>>
>> On 6 Sep 2011, at 12:36, Christian Schneider wrote:
>>
>>> Btw. I just compiled the unchanged camel-extra components against my current camel trunk and they showed no compile or test failures.
>>> So I hope we can fix the problem you see quite fast.
>>>
>>> Christian
>>>
>>>
>>> Am 06.09.2011 12:50, schrieb Christian Schneider:
>>>> Hi bvahdat,
>>>>
>>>> this is important feedback. Can you give me the compile failures. I will make sure this will be compatible.
>>>> We are currently at a snapshot. So stuff is not in release quality. Btw. this is why I would like to do a release candidate.
>>>> It is great you already tested this but many people will only do this with some "official" release.
>>>>
>>>> Christian
>>>>
>>>>
>>>> Am 06.09.2011 08:06, schrieb bvahdat:
>>>>> Hi All,
>>>>>
>>>>> the use-case Claus gave as an example in his last post indeed happened today
>>>>> morning with my client to whom I've provided the application (running stable
>>>>> since July 27th with camel 2.8.0 in the production).
>>>>>
>>>>> I wanted to give a try to the snapshot build of today morning at [1], and
>>>>> following what I see:
>>>>>
>>>>> - The code doesn't even compile, and maven-compile-plugin fails (while doing
>>>>> 'mvn install') with a bunch of compilation errors, however I didn't have
>>>>> time enough to see where/why these happen. I'll dig into it later.
>>>>>
>>>>> - And there're 14 test cases now suddenly failing, mostly by the own
>>>>> component (zls) which does logging of different events to the
>>>>> central-logging-system of the client as the payloads pass through different
>>>>> endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
>>>>> time is used for Auditing of the client applications.
>>>>>
>>>>> So at least to me this refactoring hysterie was not as smooth as it was
>>>>> claimed to be. Being a camel user in the last 10 months was really a great
>>>>> fun to me... And it's a pity to see what's going on by the camel community
>>>>> today!
>>>>>
>>>>> Regards, Babak
>>>>>
>>>>> [1]
>>>>> https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
>>>>>
>>>>> --
>>>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> 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] - API stability in Camel 2.x
Posted by Rob Davies <ra...@gmail.com>.
Mmm - seems still to be there (on SendDefinition). I'm deriving a class from WireTapDefinition - which can no longer find getUriOrRef() moving from camel 2.7 to 2.8 :)
On 8 Sep 2011, at 11:59, Rob Davies wrote:
> getUriOrRef() was removed from ProcessDefinition between Camel 2.7 and Camel 2.8 (not even deprecated) - what's the thinking behind that ?
>
> thanks,
>
> Rob
>
> On 6 Sep 2011, at 12:36, Christian Schneider wrote:
>
>> Btw. I just compiled the unchanged camel-extra components against my current camel trunk and they showed no compile or test failures.
>> So I hope we can fix the problem you see quite fast.
>>
>> Christian
>>
>>
>> Am 06.09.2011 12:50, schrieb Christian Schneider:
>>> Hi bvahdat,
>>>
>>> this is important feedback. Can you give me the compile failures. I will make sure this will be compatible.
>>> We are currently at a snapshot. So stuff is not in release quality. Btw. this is why I would like to do a release candidate.
>>> It is great you already tested this but many people will only do this with some "official" release.
>>>
>>> Christian
>>>
>>>
>>> Am 06.09.2011 08:06, schrieb bvahdat:
>>>> Hi All,
>>>>
>>>> the use-case Claus gave as an example in his last post indeed happened today
>>>> morning with my client to whom I've provided the application (running stable
>>>> since July 27th with camel 2.8.0 in the production).
>>>>
>>>> I wanted to give a try to the snapshot build of today morning at [1], and
>>>> following what I see:
>>>>
>>>> - The code doesn't even compile, and maven-compile-plugin fails (while doing
>>>> 'mvn install') with a bunch of compilation errors, however I didn't have
>>>> time enough to see where/why these happen. I'll dig into it later.
>>>>
>>>> - And there're 14 test cases now suddenly failing, mostly by the own
>>>> component (zls) which does logging of different events to the
>>>> central-logging-system of the client as the payloads pass through different
>>>> endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
>>>> time is used for Auditing of the client applications.
>>>>
>>>> So at least to me this refactoring hysterie was not as smooth as it was
>>>> claimed to be. Being a camel user in the last 10 months was really a great
>>>> fun to me... And it's a pity to see what's going on by the camel community
>>>> today!
>>>>
>>>> Regards, Babak
>>>>
>>>> [1]
>>>> https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
>>>>
>>>> --
>>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Rob Davies <ra...@gmail.com>.
getUriOrRef() was removed from ProcessDefinition between Camel 2.7 and Camel 2.8 (not even deprecated) - what's the thinking behind that ?
thanks,
Rob
On 6 Sep 2011, at 12:36, Christian Schneider wrote:
> Btw. I just compiled the unchanged camel-extra components against my current camel trunk and they showed no compile or test failures.
> So I hope we can fix the problem you see quite fast.
>
> Christian
>
>
> Am 06.09.2011 12:50, schrieb Christian Schneider:
>> Hi bvahdat,
>>
>> this is important feedback. Can you give me the compile failures. I will make sure this will be compatible.
>> We are currently at a snapshot. So stuff is not in release quality. Btw. this is why I would like to do a release candidate.
>> It is great you already tested this but many people will only do this with some "official" release.
>>
>> Christian
>>
>>
>> Am 06.09.2011 08:06, schrieb bvahdat:
>>> Hi All,
>>>
>>> the use-case Claus gave as an example in his last post indeed happened today
>>> morning with my client to whom I've provided the application (running stable
>>> since July 27th with camel 2.8.0 in the production).
>>>
>>> I wanted to give a try to the snapshot build of today morning at [1], and
>>> following what I see:
>>>
>>> - The code doesn't even compile, and maven-compile-plugin fails (while doing
>>> 'mvn install') with a bunch of compilation errors, however I didn't have
>>> time enough to see where/why these happen. I'll dig into it later.
>>>
>>> - And there're 14 test cases now suddenly failing, mostly by the own
>>> component (zls) which does logging of different events to the
>>> central-logging-system of the client as the payloads pass through different
>>> endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
>>> time is used for Auditing of the client applications.
>>>
>>> So at least to me this refactoring hysterie was not as smooth as it was
>>> claimed to be. Being a camel user in the last 10 months was really a great
>>> fun to me... And it's a pity to see what's going on by the camel community
>>> today!
>>>
>>> Regards, Babak
>>>
>>> [1]
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Btw. I just compiled the unchanged camel-extra components against my
current camel trunk and they showed no compile or test failures.
So I hope we can fix the problem you see quite fast.
Christian
Am 06.09.2011 12:50, schrieb Christian Schneider:
> Hi bvahdat,
>
> this is important feedback. Can you give me the compile failures. I
> will make sure this will be compatible.
> We are currently at a snapshot. So stuff is not in release quality.
> Btw. this is why I would like to do a release candidate.
> It is great you already tested this but many people will only do this
> with some "official" release.
>
> Christian
>
>
> Am 06.09.2011 08:06, schrieb bvahdat:
>> Hi All,
>>
>> the use-case Claus gave as an example in his last post indeed
>> happened today
>> morning with my client to whom I've provided the application (running
>> stable
>> since July 27th with camel 2.8.0 in the production).
>>
>> I wanted to give a try to the snapshot build of today morning at [1],
>> and
>> following what I see:
>>
>> - The code doesn't even compile, and maven-compile-plugin fails
>> (while doing
>> 'mvn install') with a bunch of compilation errors, however I didn't have
>> time enough to see where/why these happen. I'll dig into it later.
>>
>> - And there're 14 test cases now suddenly failing, mostly by the own
>> component (zls) which does logging of different events to the
>> central-logging-system of the client as the payloads pass through
>> different
>> endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the
>> same
>> time is used for Auditing of the client applications.
>>
>> So at least to me this refactoring hysterie was not as smooth as it was
>> claimed to be. Being a camel user in the last 10 months was really a
>> great
>> fun to me... And it's a pity to see what's going on by the camel
>> community
>> today!
>>
>> Regards, Babak
>>
>> [1]
>> https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi bvahdat,
this is important feedback. Can you give me the compile failures. I will
make sure this will be compatible.
We are currently at a snapshot. So stuff is not in release quality. Btw.
this is why I would like to do a release candidate.
It is great you already tested this but many people will only do this
with some "official" release.
Christian
Am 06.09.2011 08:06, schrieb bvahdat:
> Hi All,
>
> the use-case Claus gave as an example in his last post indeed happened today
> morning with my client to whom I've provided the application (running stable
> since July 27th with camel 2.8.0 in the production).
>
> I wanted to give a try to the snapshot build of today morning at [1], and
> following what I see:
>
> - The code doesn't even compile, and maven-compile-plugin fails (while doing
> 'mvn install') with a bunch of compilation errors, however I didn't have
> time enough to see where/why these happen. I'll dig into it later.
>
> - And there're 14 test cases now suddenly failing, mostly by the own
> component (zls) which does logging of different events to the
> central-logging-system of the client as the payloads pass through different
> endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
> time is used for Auditing of the client applications.
>
> So at least to me this refactoring hysterie was not as smooth as it was
> claimed to be. Being a camel user in the last 10 months was really a great
> fun to me... And it's a pity to see what's going on by the camel community
> today!
>
> Regards, Babak
>
> [1]
> https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by bvahdat <ba...@swissonline.ch>.
Hi All,
the use-case Claus gave as an example in his last post indeed happened today
morning with my client to whom I've provided the application (running stable
since July 27th with camel 2.8.0 in the production).
I wanted to give a try to the snapshot build of today morning at [1], and
following what I see:
- The code doesn't even compile, and maven-compile-plugin fails (while doing
'mvn install') with a bunch of compilation errors, however I didn't have
time enough to see where/why these happen. I'll dig into it later.
- And there're 14 test cases now suddenly failing, mostly by the own
component (zls) which does logging of different events to the
central-logging-system of the client as the payloads pass through different
endpoints (camel-jms, camel-jpa, camel-spring-ws, etc.), which at the same
time is used for Auditing of the client applications.
So at least to me this refactoring hysterie was not as smooth as it was
claimed to be. Being a camel user in the last 10 months was really a great
fun to me... And it's a pity to see what's going on by the camel community
today!
Regards, Babak
[1]
https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel/2.9-SNAPSHOT/
--
View this message in context: http://camel.465427.n5.nabble.com/DISCUSS-API-stability-in-Camel-2-x-tp4770632p4773307.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Wow .. you invested some time in that story below :-)
The problem is that it is not the true story.
Let´s say we are on 2.8.x. If we neeed bug fixes only then we upgrade to
a higher bug fix version. In this version there will be no functional
changes so no problems should
occur.
If we move from 2.8.x to 2.9.0 we expect functional changes and very
little or no API changes. If you look at it that should be true. During
my changes I normally did not have to change the examples
and I did not change all components so a lot of them currently work with
the compatibility classes. So the compatibility measures I did should
work quite well. If we also do a release candidate then even external
component developers have the chance to say if they are hit by
incompatibilities and we can react properly.
What do you mean by taking hostage? I do the changes in the open and
react to concerns you and others voice. For each concern we found a
solution that you were content with.
So why is 3.0 too late? I thought I had explained it. If we start the
API changes in 3.0 then we either must make every change incompatible or
we can not remove deprecated methods. But if we introduce compatibility
measures in 3.0 then we can only remove these in 4.0 which would be
really late.
Your spring example below is deeply flawed. You compared spring bugfix
releases with camel minor releases. This is definately not the same.
In spring 3.0 they really removed some deprecated classes. So they had
incompatible changes. In sum of course spring stayed much more stable
than camel. This is because they invested in a good architecture from
the start. In camel the architecture of camel-core is only a a set of
rough categories like model, builder ... These help where to put stuff
but do not help in designing the dependencies. I do not know the
architectural rules behind spring but you can be sure they have them and
make sure they are respected. The result is that spring has no
dependency cycles between packets. This is mainly thanks to Jürgen
Höller who is in charge of the spring architecture and takes a close
look at these things. Camel-core on the other hand is in fact one big
dependency cycle.
http://www.headwaysoftware.com/blog/2006/09/spring-2s-architecture-a-single-dependency-cycle-slipped-in/
http://www.structure101.com/java/tracker/spring/3.0.0.RC1/matrix.html
That is how camel looks like:
http://www.liquid-reality.de/display/liquid/2011/08/24/Understanding+and+Refactoring+the+architecture+of+camel-core
So we have to clean up a lot to be anywhere near the architectural
quality of spring. So in my opinion we need many changes and with the
3.0 release we have the chance to make them quite radically. Of course I
know that our customers are not much interested in these changes. They
are interested in getting features and fixes fast. But WE should be
interested in a good architecture as it is the basis of delivering fast
in the future.
Christian
Am 06.09.2011 07:03, schrieb Claus Ibsen:
> On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Hi Claus,
>>
>> I am trying to give the community a smooth transition to 3.0 by my current
>> changes.
>>
>> Whereever possible I use a deprecated class in the old place. So someone who
>> changes to camel 2.9.0 should have no problems.
>> He will see deprecation warnings though and this is a good thing. It will
>> allow him to then adapt to the changes while staying on 2.9.0. Then when
>> he switches to 3.0.0 he will again have almost nothing to change.
>>
>> If we do not do changes now and do everything in 3.0 then people will have a
>> very incompatible upgrade from 2.x to 3.0. So I think now with 2.9.x being
>> the last 2.x minor version it is exactly the right time to do these changes.
>> Of course you are right that it is very difficult to do the design right. So
>> we should look at it together and discuss how things should look like. If we
>> wait with this till 3.0 then it is too late. If I experiment in a private
>> branch then no one will look at the changes
>> and no discussion will occur.
>>
> What do you mean by 3.0 is too late?
>
> So you would rather take the entire Camel community as "hostage"
> (sorry I cant find a better word) by API changes directly on the
> trunk? Than use a new branch which gives you, the Camel team and
> people from the community time to work on the API without side
> effects, of our existing community users.
>
> Frankly this is how other projects do it. They create a new major
> release where they do non backwards API changes,
> key API changes which is needed to make the product better etc.
>
> Apache ServiceMix team have created a branch for their upcoming SMX 5.0 release.
> Apache Karaf team have created a branch for their upcoming Karaf 3.0 release.
> Apache ActiveMQ created a new branch for their upcoming ActiveMQ 6.0
> release. (This release is actually a total overhaul and based on a new
> architecture)
>
> Neither of those projects created a lot of API changes prior in the
> current release branches, *before* they got started on their new major
> release.
>
> If you look outside Apache, the for example the Spring framework do
> neither this. If we compare Camel and Spring then the releases would
> roughly match up as below. Notice that we in the Camel team have this
> history of doing a quarterly minor release, and hence why the versions
> match up as below:
>
> Camel 2.0 = Spring 3.0.0
> Camel 2.1 = Spring 3.0.1
> Camel 2.2 = Spring 3.0.2
> Camel 2.3 = Spring 3.0.3
> ...
>
> Not anytime in the Spring 3.0.x release have the Spring team started
> to move around classes and mark the API as @deprecated and whatnot,
> just because they want people a "smooth transition" to Spring 3.1.
> They actually respect the community and keep the API stable.
>
>
> Now imagine this use-case from which could be from the real life.
>
> Developer: We need to upgrade Camel in this production application
> Manager: Why?
> Developer: It fixes this bug we have, and also it improved this issue as well
> Manager: How long time will it take?
> Developer: I do not know, as the release notes say, that there is many
> API changes and non backwards compatible breakings
> Manager: Has this happened before?
> Developer: No this is the first time. I though Camel 2.x was an old,
> mature and stable product.
> Manager: Will this upgrade affect other products?
> Developer: Yes possible. We have those 3 custom in-house Camel
> components which most likely would be affected.
> Developer: And these components is shared by the 5 other Camel
> applications we have in production. And the 2 new projects we have in
> development currently.
> Manager: So you are saying that we need to upgrade Camel to fix this
> bug. But we cannot upfront have a qualified overview of the
> consequences?
> Developer: Yes
> Manager: So I need to quad-double my budget for this upgrade. And
> impose changes and risks in other projects as well.
> Manager: What would be the consequences for not upgrading?
> Developer: We have this bug in production
> Manager: Is there a workaround?
> Developer: Possible as the bug is fixed in a later Camel release. We
> may be able to patch the current version of Camel with the fix
> Manager: How long time will this take?
> Developer: Much less than upgrading Camel.
> Manager: Okay I want you to look into patching that bug, instead of upgrading.
> Manager: Hmm so you are saying that by relying on Camel in our
> business, we have this risk of upgrade pains, that is hard to estimate
> the consequences of, takes longer time, and costs more money
> Manager: I want a new team setup tomorrow that starts looking for
> alternatives for Camel. I don't want this problem in the future.
>
>
>
>
>
>> Christian
>>
>>
>> Am 05.09.2011 16:04, schrieb Claus Ibsen:
>>> Hi
>>>
>>> I am writing this mail with a "community hat" as well being a very
>>> concerned Camel team member.
>>>
>>> The API in camel-core had a fair number of changes recently, which is
>>> a strong concern from a community point of view.
>>> Basically the community views Camel 2.x as an mature and well
>>> established project, but also an "old and stable" product because of
>>> Camel 2.x being 2+ years old.
>>>
>>> In summary the community wants in Camel 2.x
>>> - NO CHANGES IN API
>>>
>>> The community do not care if class is named X or placed in Y etc. The
>>> community care about that the class is kept named X and kept placed in
>>> Y.
>>>
>>> That said, API changes is needed from time to time, and this is why
>>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>>> source code etc. And possible some JIRA tickets.
>>>
>>> Then when a new major version is in the works such as Camel 3.0, then
>>> those API changes can be executed.
>>> In fact designing an API is a bigger challenge than at first thought.
>>> Today you feel class X should be named and placed in Y package. To
>>> days later it should be named X2 and placed in Z package instead. To
>>> give amble time for API changes to settled down, and see how it "works
>>> out" then milestone releases of the 3.0 is being released. This gives
>>> the community and early adopters a changes to help out and give
>>> feedback. This is common practice and how other projects do.
>>>
>>> The Apache Camel 2.x project is a very successful project and its
>>> usage have reached beyond what you may see as a typical situation. We
>>> have many other open source projects which integrate directly with
>>> Camel in their products. We have other open source projects and
>>> commercial products that is based on top of Camel, or using Camel
>>> heavily internally. Their most likely use
>>> the API in ways the typical end user does not. So bottom line the
>>> exposed API is in use out there.
>>>
>>> The Camel team ove to the community to keep the API stable regardless
>>> if a class could be renamed to X to have a bit better name etc.
>>>
>>> Likewise it does not give confort in the community if the API is kept
>>> changing and their use of the API keeps being @deprecated.
>>> So when they compile or upgrade to a new version, they get scared
>>> because of the sheer number of @deprecate warnings.
>>> It is a costly $$$ for any organization to change source code, as
>>> often rigors testing and procedures kicks in, when the source code
>>> must be changed.
>>>
>>> Likewise the Apache Camel subversion repository on trunk, is not a
>>> personal * experiment* branch where the Camel committers should "play"
>>> and move around with classes and whatnot. It would be better to setup
>>> a branch or a personal project on github etc to work on the expriment
>>> (for example as I did with the simple language improvements project).
>>>
>>>
>>> From community point of view. Keep the API stable in our "old" and
>>> beloved Camel 2.x product.
>>>
>>> From community point of view. Start a discussion about Camel 3.0, as
>>> we think the Camel 2.x product is "old and stable".
>>> But the community would like a brand new Camel 3.0 in early 2012.
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 5, 2011 at 4:39 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Claus,
>
> I am trying to give the community a smooth transition to 3.0 by my current
> changes.
>
> Whereever possible I use a deprecated class in the old place. So someone who
> changes to camel 2.9.0 should have no problems.
> He will see deprecation warnings though and this is a good thing. It will
> allow him to then adapt to the changes while staying on 2.9.0. Then when
> he switches to 3.0.0 he will again have almost nothing to change.
>
> If we do not do changes now and do everything in 3.0 then people will have a
> very incompatible upgrade from 2.x to 3.0. So I think now with 2.9.x being
> the last 2.x minor version it is exactly the right time to do these changes.
> Of course you are right that it is very difficult to do the design right. So
> we should look at it together and discuss how things should look like. If we
> wait with this till 3.0 then it is too late. If I experiment in a private
> branch then no one will look at the changes
> and no discussion will occur.
>
What do you mean by 3.0 is too late?
So you would rather take the entire Camel community as "hostage"
(sorry I cant find a better word) by API changes directly on the
trunk? Than use a new branch which gives you, the Camel team and
people from the community time to work on the API without side
effects, of our existing community users.
Frankly this is how other projects do it. They create a new major
release where they do non backwards API changes,
key API changes which is needed to make the product better etc.
Apache ServiceMix team have created a branch for their upcoming SMX 5.0 release.
Apache Karaf team have created a branch for their upcoming Karaf 3.0 release.
Apache ActiveMQ created a new branch for their upcoming ActiveMQ 6.0
release. (This release is actually a total overhaul and based on a new
architecture)
Neither of those projects created a lot of API changes prior in the
current release branches, *before* they got started on their new major
release.
If you look outside Apache, the for example the Spring framework do
neither this. If we compare Camel and Spring then the releases would
roughly match up as below. Notice that we in the Camel team have this
history of doing a quarterly minor release, and hence why the versions
match up as below:
Camel 2.0 = Spring 3.0.0
Camel 2.1 = Spring 3.0.1
Camel 2.2 = Spring 3.0.2
Camel 2.3 = Spring 3.0.3
...
Not anytime in the Spring 3.0.x release have the Spring team started
to move around classes and mark the API as @deprecated and whatnot,
just because they want people a "smooth transition" to Spring 3.1.
They actually respect the community and keep the API stable.
Now imagine this use-case from which could be from the real life.
Developer: We need to upgrade Camel in this production application
Manager: Why?
Developer: It fixes this bug we have, and also it improved this issue as well
Manager: How long time will it take?
Developer: I do not know, as the release notes say, that there is many
API changes and non backwards compatible breakings
Manager: Has this happened before?
Developer: No this is the first time. I though Camel 2.x was an old,
mature and stable product.
Manager: Will this upgrade affect other products?
Developer: Yes possible. We have those 3 custom in-house Camel
components which most likely would be affected.
Developer: And these components is shared by the 5 other Camel
applications we have in production. And the 2 new projects we have in
development currently.
Manager: So you are saying that we need to upgrade Camel to fix this
bug. But we cannot upfront have a qualified overview of the
consequences?
Developer: Yes
Manager: So I need to quad-double my budget for this upgrade. And
impose changes and risks in other projects as well.
Manager: What would be the consequences for not upgrading?
Developer: We have this bug in production
Manager: Is there a workaround?
Developer: Possible as the bug is fixed in a later Camel release. We
may be able to patch the current version of Camel with the fix
Manager: How long time will this take?
Developer: Much less than upgrading Camel.
Manager: Okay I want you to look into patching that bug, instead of upgrading.
Manager: Hmm so you are saying that by relying on Camel in our
business, we have this risk of upgrade pains, that is hard to estimate
the consequences of, takes longer time, and costs more money
Manager: I want a new team setup tomorrow that starts looking for
alternatives for Camel. I don't want this problem in the future.
> Christian
>
>
> Am 05.09.2011 16:04, schrieb Claus Ibsen:
>>
>> Hi
>>
>> I am writing this mail with a "community hat" as well being a very
>> concerned Camel team member.
>>
>> The API in camel-core had a fair number of changes recently, which is
>> a strong concern from a community point of view.
>> Basically the community views Camel 2.x as an mature and well
>> established project, but also an "old and stable" product because of
>> Camel 2.x being 2+ years old.
>>
>> In summary the community wants in Camel 2.x
>> - NO CHANGES IN API
>>
>> The community do not care if class is named X or placed in Y etc. The
>> community care about that the class is kept named X and kept placed in
>> Y.
>>
>> That said, API changes is needed from time to time, and this is why
>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>> source code etc. And possible some JIRA tickets.
>>
>> Then when a new major version is in the works such as Camel 3.0, then
>> those API changes can be executed.
>> In fact designing an API is a bigger challenge than at first thought.
>> Today you feel class X should be named and placed in Y package. To
>> days later it should be named X2 and placed in Z package instead. To
>> give amble time for API changes to settled down, and see how it "works
>> out" then milestone releases of the 3.0 is being released. This gives
>> the community and early adopters a changes to help out and give
>> feedback. This is common practice and how other projects do.
>>
>> The Apache Camel 2.x project is a very successful project and its
>> usage have reached beyond what you may see as a typical situation. We
>> have many other open source projects which integrate directly with
>> Camel in their products. We have other open source projects and
>> commercial products that is based on top of Camel, or using Camel
>> heavily internally. Their most likely use
>> the API in ways the typical end user does not. So bottom line the
>> exposed API is in use out there.
>>
>> The Camel team ove to the community to keep the API stable regardless
>> if a class could be renamed to X to have a bit better name etc.
>>
>> Likewise it does not give confort in the community if the API is kept
>> changing and their use of the API keeps being @deprecated.
>> So when they compile or upgrade to a new version, they get scared
>> because of the sheer number of @deprecate warnings.
>> It is a costly $$$ for any organization to change source code, as
>> often rigors testing and procedures kicks in, when the source code
>> must be changed.
>>
>> Likewise the Apache Camel subversion repository on trunk, is not a
>> personal * experiment* branch where the Camel committers should "play"
>> and move around with classes and whatnot. It would be better to setup
>> a branch or a personal project on github etc to work on the expriment
>> (for example as I did with the simple language improvements project).
>>
>>
>> From community point of view. Keep the API stable in our "old" and
>> beloved Camel 2.x product.
>>
>> From community point of view. Start a discussion about Camel 3.0, as
>> we think the Camel 2.x product is "old and stable".
>> But the community would like a brand new Camel 3.0 in early 2012.
>>
>>
>>
>>
>>
>
>
> --
> --
> 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] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Claus,
I am trying to give the community a smooth transition to 3.0 by my
current changes.
Whereever possible I use a deprecated class in the old place. So someone
who changes to camel 2.9.0 should have no problems.
He will see deprecation warnings though and this is a good thing. It
will allow him to then adapt to the changes while staying on 2.9.0. Then
when
he switches to 3.0.0 he will again have almost nothing to change.
If we do not do changes now and do everything in 3.0 then people will
have a very incompatible upgrade from 2.x to 3.0. So I think now with
2.9.x being the last 2.x minor version it is exactly the right time to
do these changes.
Of course you are right that it is very difficult to do the design
right. So we should look at it together and discuss how things should
look like. If we wait with this till 3.0 then it is too late. If I
experiment in a private branch then no one will look at the changes
and no discussion will occur.
Christian
Am 05.09.2011 16:04, schrieb Claus Ibsen:
> Hi
>
> I am writing this mail with a "community hat" as well being a very
> concerned Camel team member.
>
> The API in camel-core had a fair number of changes recently, which is
> a strong concern from a community point of view.
> Basically the community views Camel 2.x as an mature and well
> established project, but also an "old and stable" product because of
> Camel 2.x being 2+ years old.
>
> In summary the community wants in Camel 2.x
> - NO CHANGES IN API
>
> The community do not care if class is named X or placed in Y etc. The
> community care about that the class is kept named X and kept placed in
> Y.
>
> That said, API changes is needed from time to time, and this is why
> you accumulate API change ideas in roadmap wiki pages, TODO in the
> source code etc. And possible some JIRA tickets.
>
> Then when a new major version is in the works such as Camel 3.0, then
> those API changes can be executed.
> In fact designing an API is a bigger challenge than at first thought.
> Today you feel class X should be named and placed in Y package. To
> days later it should be named X2 and placed in Z package instead. To
> give amble time for API changes to settled down, and see how it "works
> out" then milestone releases of the 3.0 is being released. This gives
> the community and early adopters a changes to help out and give
> feedback. This is common practice and how other projects do.
>
> The Apache Camel 2.x project is a very successful project and its
> usage have reached beyond what you may see as a typical situation. We
> have many other open source projects which integrate directly with
> Camel in their products. We have other open source projects and
> commercial products that is based on top of Camel, or using Camel
> heavily internally. Their most likely use
> the API in ways the typical end user does not. So bottom line the
> exposed API is in use out there.
>
> The Camel team ove to the community to keep the API stable regardless
> if a class could be renamed to X to have a bit better name etc.
>
> Likewise it does not give confort in the community if the API is kept
> changing and their use of the API keeps being @deprecated.
> So when they compile or upgrade to a new version, they get scared
> because of the sheer number of @deprecate warnings.
> It is a costly $$$ for any organization to change source code, as
> often rigors testing and procedures kicks in, when the source code
> must be changed.
>
> Likewise the Apache Camel subversion repository on trunk, is not a
> personal * experiment* branch where the Camel committers should "play"
> and move around with classes and whatnot. It would be better to setup
> a branch or a personal project on github etc to work on the expriment
> (for example as I did with the simple language improvements project).
>
>
> From community point of view. Keep the API stable in our "old" and
> beloved Camel 2.x product.
>
> From community point of view. Start a discussion about Camel 3.0, as
> we think the Camel 2.x product is "old and stable".
> But the community would like a brand new Camel 3.0 in early 2012.
>
>
>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Robert Davies <ra...@gmail.com>.
On Mon, Sep 5, 2011 at 4:54 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Maybe one way to solve those problems would be to start a 3.0 branch
> and experiment / allow more api changes there and keep trunk stable
> for some time, then later switch when 3.0 begins to have more focus.
>
>
+1. I honestly don't expect API changes at all between point releases
(upgrading between 2.7 and 2.8 hasn't been smooth - and I don't want to
change everything again for 2.9)
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Guillaume Nodet <gn...@gmail.com>.
Maybe one way to solve those problems would be to start a 3.0 branch
and experiment / allow more api changes there and keep trunk stable
for some time, then later switch when 3.0 begins to have more focus.
On Mon, Sep 5, 2011 at 17:44, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian <hz...@gmail.com> wrote:
>> Claus,
>>
>> How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
>>
>
> I guess writing all caps was a way of getting attention.
> The phrase should possible have been: KEEP API CHANGES TO A MINIMUM!
>
> I am not "the spokesman" as we *all* get exposed to the community.
> But here is a few points from my exposure.
>
> I have been around the Camel community for a long time. I work on
> Camel every day for a long time. I have been around at conferences
> giving talks on Camel and being in touch with many exiting Camel
> users, and new users as well. Likewise I get in touch with other
> communities who integrates or want to integrate with Camel. Likewise
> commercial companies of all sort get in touch with me via my employeer
> to discuss Camel etc.
>
> Likewise we have the long term history of the Camel project and how
> things works the usual way. Back in the days when we did Camel 1.x to
> 2.0 we did *not* change the API in 1.x, but crafted a new 2.0 API and
> released milestone releases and whatnot.
> Prior to this we discussed the key API changes we wanted to do for
> 2.0, such as removing the specialized exchanges, and only keen one =
> DefaultExchange. Likewise the removal of the FaultMessage, and so on.
>
> What I hear from people and vendors is that they love Camel when the
> API in 2.x started to settle down from Camel 2.4 onwards. We had a few
> bumpy releases in the earlier Camel 2.x lifetime. Some of this can be
> expected in a new major release etc.
> They do not expect this to happen again now that Camel 2.x has been
> around for 2+ years, the API is settled down, and the project is very
> successful and they can rely on the API being as is.
>
>
>> The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
>>
>
> Yes some changes in the API is okay. For example if there is issues
> reported by the community. Or that we can archive major wins such as
> better performance, reduced memory footprint and whatnot. Also API
> changes in the DSL may be more tolerable, as the DSL is very end user
> targeted, and end users would often recompile the Camel apps with the
> new Camel version. Where as changes in component API is harder, as end
> users may very well use 3rd party components which they dont recompile
> or maintain themselves. Or the component maintainers dont want to keep
> maintaing their components because Camel API changes every time.
> Also we have other open source projects which integrates with Camel
> and rely on API being stable etc. If we keep changing it, we just
> loose those other open source projects, as they can't always spend
> time and energy to keep up with Camel API changes.
>
>
> Also Christian just started this "out of the blue" without any
> consensus from the Camel team, prior discussions, request from the
> community, as well the timing was a bit off, as he started during the
> summer holiday.
>
> I am sure the internal API refactorings is nice. But every time you
> change something you risk introducing new bugs. In fact he did, which
> some I was able to point out. However we have a lot of unit tests
> which often help pickup against regressions. But there is always a
> risk.
>
> So if Christian could keep his toes to internal low risk refactorings
> that would be nice.
> The community would appreciate that the 2.x API is stable.
>
> Then I would suggest Christian started a Camel 3.0 discussion, and he
> could be a key figure in getting the new API settled down, and help
> splitup the camel-core into smaller pieces where it makes sense. When
> that API is settled a bit and takes form, then we could look at the
> "gap" from 3.0 to 2.x and put in migration guides, and possible some
> @deprecations in the 2.x API. We should not do it the "wrong way
> around" by experimenting with the 2.x API.
>
>
>
>> Hadrian
>>
>>
>>
>> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> I am writing this mail with a "community hat" as well being a very
>>> concerned Camel team member.
>>>
>>> The API in camel-core had a fair number of changes recently, which is
>>> a strong concern from a community point of view.
>>> Basically the community views Camel 2.x as an mature and well
>>> established project, but also an "old and stable" product because of
>>> Camel 2.x being 2+ years old.
>>>
>>> In summary the community wants in Camel 2.x
>>> - NO CHANGES IN API
>>>
>>> The community do not care if class is named X or placed in Y etc. The
>>> community care about that the class is kept named X and kept placed in
>>> Y.
>>>
>>> That said, API changes is needed from time to time, and this is why
>>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>>> source code etc. And possible some JIRA tickets.
>>>
>>> Then when a new major version is in the works such as Camel 3.0, then
>>> those API changes can be executed.
>>> In fact designing an API is a bigger challenge than at first thought.
>>> Today you feel class X should be named and placed in Y package. To
>>> days later it should be named X2 and placed in Z package instead. To
>>> give amble time for API changes to settled down, and see how it "works
>>> out" then milestone releases of the 3.0 is being released. This gives
>>> the community and early adopters a changes to help out and give
>>> feedback. This is common practice and how other projects do.
>>>
>>> The Apache Camel 2.x project is a very successful project and its
>>> usage have reached beyond what you may see as a typical situation. We
>>> have many other open source projects which integrate directly with
>>> Camel in their products. We have other open source projects and
>>> commercial products that is based on top of Camel, or using Camel
>>> heavily internally. Their most likely use
>>> the API in ways the typical end user does not. So bottom line the
>>> exposed API is in use out there.
>>>
>>> The Camel team ove to the community to keep the API stable regardless
>>> if a class could be renamed to X to have a bit better name etc.
>>>
>>> Likewise it does not give confort in the community if the API is kept
>>> changing and their use of the API keeps being @deprecated.
>>> So when they compile or upgrade to a new version, they get scared
>>> because of the sheer number of @deprecate warnings.
>>> It is a costly $$$ for any organization to change source code, as
>>> often rigors testing and procedures kicks in, when the source code
>>> must be changed.
>>>
>>> Likewise the Apache Camel subversion repository on trunk, is not a
>>> personal * experiment* branch where the Camel committers should "play"
>>> and move around with classes and whatnot. It would be better to setup
>>> a branch or a personal project on github etc to work on the expriment
>>> (for example as I did with the simple language improvements project).
>>>
>>>
>>> From community point of view. Keep the API stable in our "old" and
>>> beloved Camel 2.x product.
>>>
>>> From community point of view. Start a discussion about Camel 3.0, as
>>> we think the Camel 2.x product is "old and stable".
>>> But the community would like a brand new Camel 3.0 in early 2012.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/
>>
>>
>
>
>
> --
> 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] - API stability in Camel 2.x
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian <hz...@gmail.com> wrote:
> Claus,
>
> How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
>
I guess writing all caps was a way of getting attention.
The phrase should possible have been: KEEP API CHANGES TO A MINIMUM!
I am not "the spokesman" as we *all* get exposed to the community.
But here is a few points from my exposure.
I have been around the Camel community for a long time. I work on
Camel every day for a long time. I have been around at conferences
giving talks on Camel and being in touch with many exiting Camel
users, and new users as well. Likewise I get in touch with other
communities who integrates or want to integrate with Camel. Likewise
commercial companies of all sort get in touch with me via my employeer
to discuss Camel etc.
Likewise we have the long term history of the Camel project and how
things works the usual way. Back in the days when we did Camel 1.x to
2.0 we did *not* change the API in 1.x, but crafted a new 2.0 API and
released milestone releases and whatnot.
Prior to this we discussed the key API changes we wanted to do for
2.0, such as removing the specialized exchanges, and only keen one =
DefaultExchange. Likewise the removal of the FaultMessage, and so on.
What I hear from people and vendors is that they love Camel when the
API in 2.x started to settle down from Camel 2.4 onwards. We had a few
bumpy releases in the earlier Camel 2.x lifetime. Some of this can be
expected in a new major release etc.
They do not expect this to happen again now that Camel 2.x has been
around for 2+ years, the API is settled down, and the project is very
successful and they can rely on the API being as is.
> The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
>
Yes some changes in the API is okay. For example if there is issues
reported by the community. Or that we can archive major wins such as
better performance, reduced memory footprint and whatnot. Also API
changes in the DSL may be more tolerable, as the DSL is very end user
targeted, and end users would often recompile the Camel apps with the
new Camel version. Where as changes in component API is harder, as end
users may very well use 3rd party components which they dont recompile
or maintain themselves. Or the component maintainers dont want to keep
maintaing their components because Camel API changes every time.
Also we have other open source projects which integrates with Camel
and rely on API being stable etc. If we keep changing it, we just
loose those other open source projects, as they can't always spend
time and energy to keep up with Camel API changes.
Also Christian just started this "out of the blue" without any
consensus from the Camel team, prior discussions, request from the
community, as well the timing was a bit off, as he started during the
summer holiday.
I am sure the internal API refactorings is nice. But every time you
change something you risk introducing new bugs. In fact he did, which
some I was able to point out. However we have a lot of unit tests
which often help pickup against regressions. But there is always a
risk.
So if Christian could keep his toes to internal low risk refactorings
that would be nice.
The community would appreciate that the 2.x API is stable.
Then I would suggest Christian started a Camel 3.0 discussion, and he
could be a key figure in getting the new API settled down, and help
splitup the camel-core into smaller pieces where it makes sense. When
that API is settled a bit and takes form, then we could look at the
"gap" from 3.0 to 2.x and put in migration guides, and possible some
@deprecations in the 2.x API. We should not do it the "wrong way
around" by experimenting with the 2.x API.
> Hadrian
>
>
>
> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
>
>> Hi
>>
>> I am writing this mail with a "community hat" as well being a very
>> concerned Camel team member.
>>
>> The API in camel-core had a fair number of changes recently, which is
>> a strong concern from a community point of view.
>> Basically the community views Camel 2.x as an mature and well
>> established project, but also an "old and stable" product because of
>> Camel 2.x being 2+ years old.
>>
>> In summary the community wants in Camel 2.x
>> - NO CHANGES IN API
>>
>> The community do not care if class is named X or placed in Y etc. The
>> community care about that the class is kept named X and kept placed in
>> Y.
>>
>> That said, API changes is needed from time to time, and this is why
>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>> source code etc. And possible some JIRA tickets.
>>
>> Then when a new major version is in the works such as Camel 3.0, then
>> those API changes can be executed.
>> In fact designing an API is a bigger challenge than at first thought.
>> Today you feel class X should be named and placed in Y package. To
>> days later it should be named X2 and placed in Z package instead. To
>> give amble time for API changes to settled down, and see how it "works
>> out" then milestone releases of the 3.0 is being released. This gives
>> the community and early adopters a changes to help out and give
>> feedback. This is common practice and how other projects do.
>>
>> The Apache Camel 2.x project is a very successful project and its
>> usage have reached beyond what you may see as a typical situation. We
>> have many other open source projects which integrate directly with
>> Camel in their products. We have other open source projects and
>> commercial products that is based on top of Camel, or using Camel
>> heavily internally. Their most likely use
>> the API in ways the typical end user does not. So bottom line the
>> exposed API is in use out there.
>>
>> The Camel team ove to the community to keep the API stable regardless
>> if a class could be renamed to X to have a bit better name etc.
>>
>> Likewise it does not give confort in the community if the API is kept
>> changing and their use of the API keeps being @deprecated.
>> So when they compile or upgrade to a new version, they get scared
>> because of the sheer number of @deprecate warnings.
>> It is a costly $$$ for any organization to change source code, as
>> often rigors testing and procedures kicks in, when the source code
>> must be changed.
>>
>> Likewise the Apache Camel subversion repository on trunk, is not a
>> personal * experiment* branch where the Camel committers should "play"
>> and move around with classes and whatnot. It would be better to setup
>> a branch or a personal project on github etc to work on the expriment
>> (for example as I did with the simple language improvements project).
>>
>>
>> From community point of view. Keep the API stable in our "old" and
>> beloved Camel 2.x product.
>>
>> From community point of view. Start a discussion about Camel 3.0, as
>> we think the Camel 2.x product is "old and stable".
>> But the community would like a brand new Camel 3.0 in early 2012.
>>
>>
>>
>>
>>
>> --
>> 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/
>
>
--
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] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Yes there are some cases where I did not create a compatibility classes.
But these should not be in the camel API. (org.apache.camel,
org.apache.camel.spi).
Of course I know that the API is not self contained and so people use
more than the API. I did it where I think the change will not affect
many or any people.
Of course we need to check this. That is why I propose a release candidate.
If you find some that should be more compatible then give me a hint and
I ifx these.
Christian
Am 06.09.2011 06:40, schrieb Claus Ibsen:
> On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom<se...@gmail.com> wrote:
>> With deprecate changes, we'll have no issues at all, so there I do not see it as a "change" at all.
>>
> Its not only deprecated changes. What we have is a mix of changes:
> 1) classes being deleted (without any prior warnings, they were not
> @deprecated etc.)
> 2) classes being moved
> 3) classes being moved, including API changes
> 4) classes being moved, and leaving a stub class as @deprecated in
> place of the old class
>
> In terms of the item #4, then that is not a 100% backwards compatible
> change. There is a couple of issues. The stub class is not active in
> use and the stub class is not unit tested. For example if the Camel
> API exposes an API which returns the given class, then with this
> change, that API will now return the new class, which causes
> ClassCastExceptions for end users who was depending on the old API.
>
>
>
>
>> /je
>> On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:
>>
>>> Claus,
>>>
>>> How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
>>>
>>> The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
>>>
>>> Hadrian
>>>
>>>
>>>
>>> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
>>>
>>>> Hi
>>>>
>>>> I am writing this mail with a "community hat" as well being a very
>>>> concerned Camel team member.
>>>>
>>>> The API in camel-core had a fair number of changes recently, which is
>>>> a strong concern from a community point of view.
>>>> Basically the community views Camel 2.x as an mature and well
>>>> established project, but also an "old and stable" product because of
>>>> Camel 2.x being 2+ years old.
>>>>
>>>> In summary the community wants in Camel 2.x
>>>> - NO CHANGES IN API
>>>>
>>>> The community do not care if class is named X or placed in Y etc. The
>>>> community care about that the class is kept named X and kept placed in
>>>> Y.
>>>>
>>>> That said, API changes is needed from time to time, and this is why
>>>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>>>> source code etc. And possible some JIRA tickets.
>>>>
>>>> Then when a new major version is in the works such as Camel 3.0, then
>>>> those API changes can be executed.
>>>> In fact designing an API is a bigger challenge than at first thought.
>>>> Today you feel class X should be named and placed in Y package. To
>>>> days later it should be named X2 and placed in Z package instead. To
>>>> give amble time for API changes to settled down, and see how it "works
>>>> out" then milestone releases of the 3.0 is being released. This gives
>>>> the community and early adopters a changes to help out and give
>>>> feedback. This is common practice and how other projects do.
>>>>
>>>> The Apache Camel 2.x project is a very successful project and its
>>>> usage have reached beyond what you may see as a typical situation. We
>>>> have many other open source projects which integrate directly with
>>>> Camel in their products. We have other open source projects and
>>>> commercial products that is based on top of Camel, or using Camel
>>>> heavily internally. Their most likely use
>>>> the API in ways the typical end user does not. So bottom line the
>>>> exposed API is in use out there.
>>>>
>>>> The Camel team ove to the community to keep the API stable regardless
>>>> if a class could be renamed to X to have a bit better name etc.
>>>>
>>>> Likewise it does not give confort in the community if the API is kept
>>>> changing and their use of the API keeps being @deprecated.
>>>> So when they compile or upgrade to a new version, they get scared
>>>> because of the sheer number of @deprecate warnings.
>>>> It is a costly $$$ for any organization to change source code, as
>>>> often rigors testing and procedures kicks in, when the source code
>>>> must be changed.
>>>>
>>>> Likewise the Apache Camel subversion repository on trunk, is not a
>>>> personal * experiment* branch where the Camel committers should "play"
>>>> and move around with classes and whatnot. It would be better to setup
>>>> a branch or a personal project on github etc to work on the expriment
>>>> (for example as I did with the simple language improvements project).
>>>>
>>>>
>>>> From community point of view. Keep the API stable in our "old" and
>>>> beloved Camel 2.x product.
>>>>
>>>> From community point of view. Start a discussion about Camel 3.0, as
>>>> we think the Camel 2.x product is "old and stable".
>>>> But the community would like a brand new Camel 3.0 in early 2012.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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/
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Sep 5, 2011 at 7:13 PM, Johan Edstrom <se...@gmail.com> wrote:
> With deprecate changes, we'll have no issues at all, so there I do not see it as a "change" at all.
>
Its not only deprecated changes. What we have is a mix of changes:
1) classes being deleted (without any prior warnings, they were not
@deprecated etc.)
2) classes being moved
3) classes being moved, including API changes
4) classes being moved, and leaving a stub class as @deprecated in
place of the old class
In terms of the item #4, then that is not a 100% backwards compatible
change. There is a couple of issues. The stub class is not active in
use and the stub class is not unit tested. For example if the Camel
API exposes an API which returns the given class, then with this
change, that API will now return the new class, which causes
ClassCastExceptions for end users who was depending on the old API.
> /je
> On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:
>
>> Claus,
>>
>> How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
>>
>> The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
>>
>> Hadrian
>>
>>
>>
>> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
>>
>>> Hi
>>>
>>> I am writing this mail with a "community hat" as well being a very
>>> concerned Camel team member.
>>>
>>> The API in camel-core had a fair number of changes recently, which is
>>> a strong concern from a community point of view.
>>> Basically the community views Camel 2.x as an mature and well
>>> established project, but also an "old and stable" product because of
>>> Camel 2.x being 2+ years old.
>>>
>>> In summary the community wants in Camel 2.x
>>> - NO CHANGES IN API
>>>
>>> The community do not care if class is named X or placed in Y etc. The
>>> community care about that the class is kept named X and kept placed in
>>> Y.
>>>
>>> That said, API changes is needed from time to time, and this is why
>>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>>> source code etc. And possible some JIRA tickets.
>>>
>>> Then when a new major version is in the works such as Camel 3.0, then
>>> those API changes can be executed.
>>> In fact designing an API is a bigger challenge than at first thought.
>>> Today you feel class X should be named and placed in Y package. To
>>> days later it should be named X2 and placed in Z package instead. To
>>> give amble time for API changes to settled down, and see how it "works
>>> out" then milestone releases of the 3.0 is being released. This gives
>>> the community and early adopters a changes to help out and give
>>> feedback. This is common practice and how other projects do.
>>>
>>> The Apache Camel 2.x project is a very successful project and its
>>> usage have reached beyond what you may see as a typical situation. We
>>> have many other open source projects which integrate directly with
>>> Camel in their products. We have other open source projects and
>>> commercial products that is based on top of Camel, or using Camel
>>> heavily internally. Their most likely use
>>> the API in ways the typical end user does not. So bottom line the
>>> exposed API is in use out there.
>>>
>>> The Camel team ove to the community to keep the API stable regardless
>>> if a class could be renamed to X to have a bit better name etc.
>>>
>>> Likewise it does not give confort in the community if the API is kept
>>> changing and their use of the API keeps being @deprecated.
>>> So when they compile or upgrade to a new version, they get scared
>>> because of the sheer number of @deprecate warnings.
>>> It is a costly $$$ for any organization to change source code, as
>>> often rigors testing and procedures kicks in, when the source code
>>> must be changed.
>>>
>>> Likewise the Apache Camel subversion repository on trunk, is not a
>>> personal * experiment* branch where the Camel committers should "play"
>>> and move around with classes and whatnot. It would be better to setup
>>> a branch or a personal project on github etc to work on the expriment
>>> (for example as I did with the simple language improvements project).
>>>
>>>
>>> From community point of view. Keep the API stable in our "old" and
>>> beloved Camel 2.x product.
>>>
>>> From community point of view. Start a discussion about Camel 3.0, as
>>> we think the Camel 2.x product is "old and stable".
>>> But the community would like a brand new Camel 3.0 in early 2012.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/
>>
>
>
--
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] - API stability in Camel 2.x
Posted by Johan Edstrom <se...@gmail.com>.
With deprecate changes, we'll have no issues at all, so there I do not see it as a "change" at all.
/je
On Sep 5, 2011, at 9:16 AM, Zbarcea Hadrian wrote:
> Claus,
>
> How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
>
> The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
>
> Hadrian
>
>
>
> On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
>
>> Hi
>>
>> I am writing this mail with a "community hat" as well being a very
>> concerned Camel team member.
>>
>> The API in camel-core had a fair number of changes recently, which is
>> a strong concern from a community point of view.
>> Basically the community views Camel 2.x as an mature and well
>> established project, but also an "old and stable" product because of
>> Camel 2.x being 2+ years old.
>>
>> In summary the community wants in Camel 2.x
>> - NO CHANGES IN API
>>
>> The community do not care if class is named X or placed in Y etc. The
>> community care about that the class is kept named X and kept placed in
>> Y.
>>
>> That said, API changes is needed from time to time, and this is why
>> you accumulate API change ideas in roadmap wiki pages, TODO in the
>> source code etc. And possible some JIRA tickets.
>>
>> Then when a new major version is in the works such as Camel 3.0, then
>> those API changes can be executed.
>> In fact designing an API is a bigger challenge than at first thought.
>> Today you feel class X should be named and placed in Y package. To
>> days later it should be named X2 and placed in Z package instead. To
>> give amble time for API changes to settled down, and see how it "works
>> out" then milestone releases of the 3.0 is being released. This gives
>> the community and early adopters a changes to help out and give
>> feedback. This is common practice and how other projects do.
>>
>> The Apache Camel 2.x project is a very successful project and its
>> usage have reached beyond what you may see as a typical situation. We
>> have many other open source projects which integrate directly with
>> Camel in their products. We have other open source projects and
>> commercial products that is based on top of Camel, or using Camel
>> heavily internally. Their most likely use
>> the API in ways the typical end user does not. So bottom line the
>> exposed API is in use out there.
>>
>> The Camel team ove to the community to keep the API stable regardless
>> if a class could be renamed to X to have a bit better name etc.
>>
>> Likewise it does not give confort in the community if the API is kept
>> changing and their use of the API keeps being @deprecated.
>> So when they compile or upgrade to a new version, they get scared
>> because of the sheer number of @deprecate warnings.
>> It is a costly $$$ for any organization to change source code, as
>> often rigors testing and procedures kicks in, when the source code
>> must be changed.
>>
>> Likewise the Apache Camel subversion repository on trunk, is not a
>> personal * experiment* branch where the Camel committers should "play"
>> and move around with classes and whatnot. It would be better to setup
>> a branch or a personal project on github etc to work on the expriment
>> (for example as I did with the simple language improvements project).
>>
>>
>> From community point of view. Keep the API stable in our "old" and
>> beloved Camel 2.x product.
>>
>> From community point of view. Start a discussion about Camel 3.0, as
>> we think the Camel 2.x product is "old and stable".
>> But the community would like a brand new Camel 3.0 in early 2012.
>>
>>
>>
>>
>>
>> --
>> 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] - API stability in Camel 2.x
Posted by Zbarcea Hadrian <hz...@gmail.com>.
Claus,
How exactly did you get to figure out what the community wants "NO CHANGES" in the the API an via what process were you nominated to express that opinion?
The reality is that the API did change in every single minor release of Camel, and my understanding is that this is an effort to actually clean it up and make sure it does not happen anymore after 3.0. The changes put on now are the painless ones that could be done before that. Afaik, you provided some useful feedback for some of these changes.
Hadrian
On Sep 5, 2011, at 10:04 AM, Claus Ibsen wrote:
> Hi
>
> I am writing this mail with a "community hat" as well being a very
> concerned Camel team member.
>
> The API in camel-core had a fair number of changes recently, which is
> a strong concern from a community point of view.
> Basically the community views Camel 2.x as an mature and well
> established project, but also an "old and stable" product because of
> Camel 2.x being 2+ years old.
>
> In summary the community wants in Camel 2.x
> - NO CHANGES IN API
>
> The community do not care if class is named X or placed in Y etc. The
> community care about that the class is kept named X and kept placed in
> Y.
>
> That said, API changes is needed from time to time, and this is why
> you accumulate API change ideas in roadmap wiki pages, TODO in the
> source code etc. And possible some JIRA tickets.
>
> Then when a new major version is in the works such as Camel 3.0, then
> those API changes can be executed.
> In fact designing an API is a bigger challenge than at first thought.
> Today you feel class X should be named and placed in Y package. To
> days later it should be named X2 and placed in Z package instead. To
> give amble time for API changes to settled down, and see how it "works
> out" then milestone releases of the 3.0 is being released. This gives
> the community and early adopters a changes to help out and give
> feedback. This is common practice and how other projects do.
>
> The Apache Camel 2.x project is a very successful project and its
> usage have reached beyond what you may see as a typical situation. We
> have many other open source projects which integrate directly with
> Camel in their products. We have other open source projects and
> commercial products that is based on top of Camel, or using Camel
> heavily internally. Their most likely use
> the API in ways the typical end user does not. So bottom line the
> exposed API is in use out there.
>
> The Camel team ove to the community to keep the API stable regardless
> if a class could be renamed to X to have a bit better name etc.
>
> Likewise it does not give confort in the community if the API is kept
> changing and their use of the API keeps being @deprecated.
> So when they compile or upgrade to a new version, they get scared
> because of the sheer number of @deprecate warnings.
> It is a costly $$$ for any organization to change source code, as
> often rigors testing and procedures kicks in, when the source code
> must be changed.
>
> Likewise the Apache Camel subversion repository on trunk, is not a
> personal * experiment* branch where the Camel committers should "play"
> and move around with classes and whatnot. It would be better to setup
> a branch or a personal project on github etc to work on the expriment
> (for example as I did with the simple language improvements project).
>
>
> From community point of view. Keep the API stable in our "old" and
> beloved Camel 2.x product.
>
> From community point of view. Start a discussion about Camel 3.0, as
> we think the Camel 2.x product is "old and stable".
> But the community would like a brand new Camel 3.0 in early 2012.
>
>
>
>
>
> --
> 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] - API stability in Camel 2.x
Posted by Willem Jiang <wi...@gmail.com>.
Hi Christian,
Here is one thing, when you introducing a new change (moving the classes
around), you may updated the unit tests as well. But it could introduce
some side effect to break the old codes, which may not covered by these
unit tests.
It will take lot time for the user to fix that build failed even he dig
the code or go through the API change list every often. We don't want
user do it unless he upgrade to Camel 3.x. And we should keep it as less
as possible.
I think that is Claus try to say when he wares the community hat.
Please think twice when you change the API, that is we learn from the
evolution of Camel 2.x.
On 9/6/11 12:13 AM, Christian Schneider wrote:
> Hi Guillaume,
>
> there are several changes I did recently. The main issue perhaps is the
> current issue I opened:
> https://issues.apache.org/jira/browse/CAMEL-4417
> This of course a very sensible area and I plan to do this very carefully
> and will create a patch to discuss before I change something.
>
> To a lower extend all my recent changes have the risk of introducing
> incompatiblilty. I tried to introduce deprecated stubs whereever I
> thought they would be needed. To further lower the risk to users I think
> we could do a 2.9 release candidate and add more compatibility classes
> where people demand them.
>
> The idea I follow is to remove the deprecated classes in 3.0 but
> introduce them now. So people have time to change their code while using
> 2.9.x and then have a smoother transition.
>
> This would be especially good for component developers. At the moment
> their components are targeted for 2.x. So with the changes in 2.9 they
> could at some point change their components to the new api
> and then they would be compatible with 2.9.x and 3.x.
>
> Christian
>
>
> Am 05.09.2011 17:51, schrieb Guillaume Nodet:
>> Can one point to the exact changes we're talking about here?
>> If those are fully compatible through using deprecation, I don't see
>> any major problem.
>> However, I don't think we should introduce incompatible changes unless
>> really required, especially as we *are* planning to do a 3.0 some time
>> in the near future, and all breaking changes should be put there.
>> Else, there's no need to call it 3.0 and 2.10 would be fine too.
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Guillaume,
there are several changes I did recently. The main issue perhaps is the
current issue I opened:
https://issues.apache.org/jira/browse/CAMEL-4417
This of course a very sensible area and I plan to do this very carefully
and will create a patch to discuss before I change something.
To a lower extend all my recent changes have the risk of introducing
incompatiblilty. I tried to introduce deprecated stubs whereever I
thought they would be needed. To further lower the risk to users I think
we could do a 2.9 release candidate and add more compatibility classes
where people demand them.
The idea I follow is to remove the deprecated classes in 3.0 but
introduce them now. So people have time to change their code while using
2.9.x and then have a smoother transition.
This would be especially good for component developers. At the moment
their components are targeted for 2.x. So with the changes in 2.9 they
could at some point change their components to the new api
and then they would be compatible with 2.9.x and 3.x.
Christian
Am 05.09.2011 17:51, schrieb Guillaume Nodet:
> Can one point to the exact changes we're talking about here?
> If those are fully compatible through using deprecation, I don't see
> any major problem.
> However, I don't think we should introduce incompatible changes unless
> really required, especially as we *are* planning to do a 3.0 some time
> in the near future, and all breaking changes should be put there.
> Else, there's no need to call it 3.0 and 2.10 would be fine too.
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSS] - API stability in Camel 2.x
Posted by Guillaume Nodet <gn...@gmail.com>.
Can one point to the exact changes we're talking about here?
If those are fully compatible through using deprecation, I don't see
any major problem.
However, I don't think we should introduce incompatible changes unless
really required, especially as we *are* planning to do a 3.0 some time
in the near future, and all breaking changes should be put there.
Else, there's no need to call it 3.0 and 2.10 would be fine too.
On Mon, Sep 5, 2011 at 16:04, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> I am writing this mail with a "community hat" as well being a very
> concerned Camel team member.
>
> The API in camel-core had a fair number of changes recently, which is
> a strong concern from a community point of view.
> Basically the community views Camel 2.x as an mature and well
> established project, but also an "old and stable" product because of
> Camel 2.x being 2+ years old.
>
> In summary the community wants in Camel 2.x
> - NO CHANGES IN API
>
> The community do not care if class is named X or placed in Y etc. The
> community care about that the class is kept named X and kept placed in
> Y.
>
> That said, API changes is needed from time to time, and this is why
> you accumulate API change ideas in roadmap wiki pages, TODO in the
> source code etc. And possible some JIRA tickets.
>
> Then when a new major version is in the works such as Camel 3.0, then
> those API changes can be executed.
> In fact designing an API is a bigger challenge than at first thought.
> Today you feel class X should be named and placed in Y package. To
> days later it should be named X2 and placed in Z package instead. To
> give amble time for API changes to settled down, and see how it "works
> out" then milestone releases of the 3.0 is being released. This gives
> the community and early adopters a changes to help out and give
> feedback. This is common practice and how other projects do.
>
> The Apache Camel 2.x project is a very successful project and its
> usage have reached beyond what you may see as a typical situation. We
> have many other open source projects which integrate directly with
> Camel in their products. We have other open source projects and
> commercial products that is based on top of Camel, or using Camel
> heavily internally. Their most likely use
> the API in ways the typical end user does not. So bottom line the
> exposed API is in use out there.
>
> The Camel team ove to the community to keep the API stable regardless
> if a class could be renamed to X to have a bit better name etc.
>
> Likewise it does not give confort in the community if the API is kept
> changing and their use of the API keeps being @deprecated.
> So when they compile or upgrade to a new version, they get scared
> because of the sheer number of @deprecate warnings.
> It is a costly $$$ for any organization to change source code, as
> often rigors testing and procedures kicks in, when the source code
> must be changed.
>
> Likewise the Apache Camel subversion repository on trunk, is not a
> personal * experiment* branch where the Camel committers should "play"
> and move around with classes and whatnot. It would be better to setup
> a branch or a personal project on github etc to work on the expriment
> (for example as I did with the simple language improvements project).
>
>
> From community point of view. Keep the API stable in our "old" and
> beloved Camel 2.x product.
>
> From community point of view. Start a discussion about Camel 3.0, as
> we think the Camel 2.x product is "old and stable".
> But the community would like a brand new Camel 3.0 in early 2012.
>
>
>
>
>
> --
> 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