Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@camel.apache.org
Subject: Re: [DISCUSS] - Trunk as Camel 3.0
Date: Fri, 23 Sep 2011 10:39:38 -0400
Message-ID: <4251121.ccGMxpGBeo@dilbert.dankulp.com>
User-Agent: KMail/4.7.1 (Linux/3.0.1; KDE/4.7.1; x86_64; ; )
In-Reply-To: <67E07EE6-84B5-4B66-AC24-74C66D598F9D@gmail.com>
References: 
 <CAGB5yNnFXwSJe8roC4hmzpky-0ATrs2Jqh548nG=Os9cG4+dNw@mail.gmail.com>
 <17104544.6u0lm9TkI6@dilbert.dankulp.com>
 <67E07EE6-84B5-4B66-AC24-74C66D598F9D@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday, September 23, 2011 3:13:02 PM Rob Davies wrote:
> The reality is that users,  want stability and they will be unwilling to
> move to versions above 2.8.x unless there's a compelling reason to do so.

So let them stay on 2.8.x.   We'll happily provide fixes for them.   We have a 
nice back porting process setup now.   I have ABSOLUTELY no problem with that.


> So if they know a 3.0 is in the works, they will wait till that version is
> GA before considering upgrading. So try to get them to transition easily by
> moving to 2.9 and 3.0 is a a red-herring. Much better to make the move to
> 3.0 now.

I cannot see how providing a migration path for some users is a bad thing.   I 
specifically have customers asking for such a path as we move forward.   They 
want to stay on 2.x line for now (likely till 3.1, fear of .0's) but still 
have a nice migration path for their app.    (and no, using a 3.0-RC1 is not 
acceptable at all)

Dan


> On 23 Sep 2011, at 15:08, Daniel Kulp wrote:
> > -1 - this makes no sense to me.   Christian and Hadrian have done a ton
> > of work to make sure those changes are completely compatible for 2.x
> > users while also providing those users a glimpse into what 3.0 will
> > look like and providing migration paths for those users.    That's a
> > *good* thing.
> > 
> > What I *would* be in favor of is:
> > 
> > Create a 2.9.x (or just 2.x) branch off of trunk now to start the final
> > stabilizing and testing of that code base on that branch.   Then make
> > trunk 3.0 and immediately remove all the @deprecated stuff there to
> > start real work toward the 3.0 release.
> > 
> > Dan
> > 
> > On Friday, September 23, 2011 1:13:56 PM Claus Ibsen wrote:
> >> Hi
> >> 
> >> I would like to propose that Camel source code currently on trunk is
> >> to be Camel 3.0.0.
> >> And the current code on the 2.8.x branch is to be used for the 2.x
> >> lifetime of Camel.
> >> 
> >> 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.
> >> 
> >> 
> >> By letting the trunk code be targeted for Camel 3.0.0, we open the
> >> ability to refactor the API more freely,
> >> and without causing trouble for our large group of 2.x Camel users,
> >> who are not expecting API changes in the camel-core at all.
> >> 
> >> Likewise the latest merges on the 2.8.x branch is already including
> >> new features and other improvements,
> >> which is a good offset for Camel 2.9.0. We can of course backport "the
> >> missings" from trunk such as:
> >> new components, and other improvements, new features, which we think
> >> is worthwhile
> >> and that the community would like to have in the Camel 2.9 release.
-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com