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<seij...@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: cib...@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
