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
