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