camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [DISCUSS] - API stability in Camel 2.x
Date Mon, 05 Sep 2011 15:44:57 GMT
On Mon, Sep 5, 2011 at 5:16 PM, Zbarcea Hadrian <hzbarcea@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/

Mime
View raw message