Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4E64F534.4020002@die-schneider.net>
Date: Mon, 05 Sep 2011 18:13:40 +0200
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] - API stability in Camel 2.x
References: 
 <CAGB5yNnfiqbnZSH+O+tt7MZ1UcZBLq0cjd_TzGN6LkiSPeT_mg@mail.gmail.com>
 <CAEQV+EHnZJ=ie=vmc-9P+PWgUYALmb5J1K0VwS5MNCuoozQnnQ@mail.gmail.com>
In-Reply-To: 
 <CAEQV+EHnZJ=ie=vmc-9P+PWgUYALmb5J1K0VwS5MNCuoozQnnQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Guillaume,

there are several changes I did recently. The main issue perhaps is  the 
current issue I opened:
https://issues.apache.org/jira/browse/CAMEL-4417
This of course a very sensible area and I plan to do this very carefully 
and will create a patch to discuss before I change something.

To a lower extend all my recent changes have the risk of introducing 
incompatiblilty. I tried to introduce deprecated stubs whereever I 
thought they would be needed. To further lower the risk to users I think 
we could do a 2.9 release candidate and add more compatibility classes 
where people demand them.

The idea I follow is to remove the deprecated classes in 3.0 but 
introduce them now. So people have time to change their code while using 
2.9.x and then have a smoother transition.

This would be especially good for component developers. At the moment 
their components are targeted for 2.x. So with the changes in 2.9 they 
could at some point change their components to the new api
and then they would be compatible with 2.9.x and 3.x.

Christian


Am 05.09.2011 17:51, schrieb Guillaume Nodet:
> Can one point to the exact changes we're talking about here?
> If those are fully compatible through using deprecation, I don't see
> any major problem.
> However, I don't think we should introduce incompatible changes unless
> really required, especially as we *are* planning to do a 3.0 some time
> in the near future, and all breaking changes should be put there.
> Else, there's no need to call it 3.0 and 2.10 would be fine too.
>
>

-- 
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com