camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Tue, 27 Sep 2011 05:51:18 GMT
On Mon, Sep 26, 2011 at 11:26 PM, Hadrian Zbarcea <> wrote:
> Not really sure to which of the many messages to reply to, I just chose this
> one. I tried to educate myself on what the issues are (obviously more than
> one). Thanks to all who helped, you know who you are.
> I understand that we all agree on the need to maintain backward
> compatibility close to 100% on minor releases and even in 3.0 as much as
> possible, and give a clear, simple migration path when not possible.
> Some of the changes for 2.9.0 did break compatibility, but with they were
> resolved in most part due to Claus' comments and his work with Christian.
> If I understand the statement below correctly, as of now the trunk is in an
> acceptable state and could continue as 2.9-SNAPSHOT. As long as other
> incompatible changes won't be introduced we are in an ok shape as far as
> backward compatibility goes. It would be a good idea to start closing down
> for a 2.9.0 release as well, use the remaining time to stabilize the trunk
> and fix remaining issues and possibly issue an early RC release for 2.9.0.


The current state of the trunk is almost in an acceptable state. We
may want to consider if
there was a few classes which was moved within a sub-package, that we
could consider
moving back for the 2.9 release, and mark them as @deprecated and to
be moved for
a future release (certainly Camel 3.0). One example is the
DefaultChannel, but there
may be a few others.

We also ought to add javadoc documentation for the @deprecated methods, to point
the user to which new method to use.

Likewise if possible to add more details to the API changes in the
release notes, so
the end users know about this in advantage.

> We should also restart the discussions about what we want in camel-3.0,
> there are already a good number of ideas floating around, and as soon as we
> have a critical mass of agreement on 3.0 improvements move the trunk to
> become 3.0-SNAPSHOT. If we need more experiments for 3.0 it is preferred to
> do them on branches or in a sandbox.
> Does this sound acceptable?


> Hadrian
>> With the current state of trunk as Camel 2.9.0, then I actually share
>> a view to release early to give the community a chance to give it a
>> spin.
>> Also because Camel 2.9.0 is *not* going to be like any other regular
>> minor releases we usually do.
>> So doing 1-2 RC releases could be a good thing for the community.

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message