On 9/25/11 9:14 AM, Hadrian Zbarcea wrote:
Ioannis, what you suggest is similar to what Christian was suggesting
except instead of a 2.9 and maybe a 2.10 who knows, you would be ok with
calling these versions 3.0, 3.1, with the intention, probably, to
accommodate Claus' proposal.
Now, to answer Willem and Rob other messages in this thread too, let's
take another look at Claus' proposal. It states:
<quote>
The reason for this can be summarized as:
1) All the API changes on trunk, and still to be done API changes
2) Preserve Camel 2.x API stability
3) Camel 2.x continue as usual
4) Camel 2.x is already 2+ years old.
5) The community would expect work on Camel 3.0 starting soon.
</quote>
1) not quite clear, I assume he means to allow more freedom in making
incompatible changes. I think this extra freedom is not that necessary
now, we should not introduce significant incompatibilities
2) Sure, we can keep doing it on 2.x, not worse than it was in all minor
versions until now.
3) Well, it does
4) So?
5) Really? Where's that coming from?
Take it easy,
In general the expectation from a major release is to come with, well,
major improvements in architecture, api, functionality, etc, and yes, a
major release may not necessarily be fully backwards compatible. See
[1], [2] and other references on the web.
From what I understand, Christian is not proposing nor making
significant improvements in the api, he's simply cleaning it up and
reducing tangles, circular dependencies that are a symptom of bad
design. This would pave the way for an improved api in 3.0.
I think already stated my +1 for a new API module to break the cycle
dependency of camel-core which was proposed by Christian.
But I don't think we should ship the camel-api module in Camel 2.9, as
it break the user experience,
As you know there are lots of components which are not in the Apache
Camel repository. Any incompatible change in the camel core may cause
some trouble for the user when they upgrade to Camel 2.9.
If we make the trunk as Camel 3.0, we can do more work than adding the
compatible classes, and we can keep on thinking to add the other great
feature of Camel3.0.
The milestone release of Camel 3.0 could help us get the user feed back
and we did it in development of Camel 2.0 without any trouble.
If we fork another branch for the Camel 2.9.0. We will have much work to
back port the patch. When we have some bug fix on the trunk, we have
to merge patch back to Camel 2.9.x, 2.8.x, 2.7.x three branches. That is
not a easy job to do.
What should be done in 3.0, at least imho, and hopefully we'll get to
the point to talk more seriously about that:
* cleanup the api an architecture to allow one to use camel as an
integration framework *without* the routing part. For instance one
should be able to use just a producer template and the components of
choice with a lean runtime (without the dsl, some processors maybe,
support for routing, etc)
* it should be lean enough to run well on mobile devices
* the threading model should be significantly improved
* better support for tools
* better support for clustering
* other tactical goals like reducing the build/test time to under 1 hour
(we made significant improvements there already, but there's still a lot
more to do); this is one area that frustrates me a lot.
* significant improvements in the test kit, components for instance
should not be unit tested using routes and RouteBuilders. Instead we
should test/assert that configuration is used as expected (positive and
negative tests), messages are produced and consumed as expected, proper
types and headers are used/set, etc.
* ... and many more that we'll discuss in due time.
Now, these kind of changes may introduce some incompatibilities and
would warrant a 3.0, but just the changes Christian made? Seriously?
Most of the above are not only my ideas, and not new, they were
discussed by different committers and users over time. I don't think we
are yet ready to fully shape a camel-3.0, and the goal is to make steps
in that direction and get ready for it.
Can you put them into the road map of camel 3.0[1], I saw Claus and
Christian updated most entry of them. We could keep track of it in the
wiki in case we forget them.
[1]http://camel.apache.org/camel-30-roadmap.html
Hadrian
[1] http://en.wikipedia.org/wiki/Software_versioning
[2] http://dictionary.reference.com/browse/major+release
On 09/24/2011 11:07 AM, Ioannis Canellos wrote:
I understand that there are two respectable views on the subject:
a) We should guarantee forward compatibility for 2.x as the major version
implies.
b) The API changes should not wait for the 3.0.0 release as its not
going to
happen any time soon.
I was wondering if it would be possible to make a fast 3.0.0 release with
the API changes and move the rest of 3.0.0 roadmap (which undoubtably
will
require more time) to release 4.0.0. The 3.x could have a short lifecycle
and could serve till we are ready to deliver the rest of the roadmap into
4.0.0. Would such a solution make sense?
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
