-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 dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
