On Sat, Sep 24, 2011 at 3:48 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > I don't think we're debating if, we're debating when. I get your point and I > would agree if this was any different than before. The reality though is > that *every* single minor release of Camel was *not* 100% backwards > compatible. We absolutely strive for backward compatibility and 2.9.0 should > not be worse. We should be 100% compatible in patch releases though. >
The previous minor releases of Camel could have API changes, but they would be at a very minimal, and not touch key areas in camel-core. This is not the case on Camel 2.9, and the JIRA tickets that Christian have assigned to himself. In fact the remainder of those tickets is suggesting big API breakings in the SPI / model packages. Likewise Hadrian committed a change to Component / Endpoint API which will break API for people. Those API changes have *not* been documented in the release notes, likewise many of the changes done by Christian. Last year we did a survey to ask for feedback, and we said the survey is to be used for Camel 3.0 planning. See this page, and link to survey in top http://camel.apache.org/camel-30-roadmap.html If you look in the comments in the survey, at the end, then people in the community, is asking for *NOT* to change the API in minor releases. > The reality is that when we'll start working on 3.x we won't have it for at > least 9 months, most likely. Nobody will migrate to a 3.0-Mx milestone > release. It's also likely that many won't migrate to a new 2.x while we > actively work on 3.x. In the patch releases we only have a small subset of > the new features on trunk. > > I know some are kinda tired of 2.x and want to look at and talk about the > next great thing. We had this discussion a year ago and promises were made > that 3.0 will be out in Q1 2011. We don't yet know how 3.0 will look like, > although many have their ideas. We know that we want a cleaner api, we know > we want it leaner and we know that we want shorter build times and other few > things. We can easily continue to work on that and the other features that > come with every release until we figure out how 3.0 will look like. Doing it > now is, imho, a distraction. > We already know what Camel 3.0 will look like. We have a roadmap up for 1 year or longer. http://camel.apache.org/camel-30-roadmap.html There is no rule, that says a developing Camel 3.0 should take 9+ months. In fact we have previously talked about doing a quick Camel 3.0 release with API changes, and internal routing engine optimizations/cleanup as primary goals. There is no rule that says Camel 3.0 has to be a total re-architecture and it must have 100+ new features and whatnot. > My $0.02, > Hadrian > > > > On 09/24/2011 08:18 AM, Hiram Chirino wrote: >> >> The fact that it's not 100% compatible IS why it's not a good idea to >> call it 2.x. The point of version numbering schemes are to reflect >> the compatibility between releases. If trunk is not a major release, >> I don't know what is. And yes I would hope that the 3.x line tries to >> keep as much backward compatible support with 2.x as possible. >> Otherwise, you've got a brand new product in your hands and your 2.x >> users will have a big wall to climb to to upgrade to the 3.x. As for >> dropping deprecated APIs, I'd do that in a 3.1 or once we verify that >> migration to 3.x is fully backward compatible from 2.x (I'm sure we >> will miss some compatibility stuff in the first few releases of 3.x). >> >> >> Regards, >> Hiram >> >> FuseSource >> Web: http://fusesource.com/ >> >> >> >> >> On Fri, Sep 23, 2011 at 11:12 AM, Christian Schneider >> <ch...@die-schneider.net> wrote: >>> >>> I just talked to Dan and Hadrian about this idea. The problem is that >>> however we would call such a release people would take it as kind of a >>> milestone and it would probably not be used much. >>> >>> So it is probably better to use the 2.9 and perhaps 2.10 release for >>> that. >>> The 2.x naming will suggest that it is mostly compatible and we can >>> mention >>> in the release not that it is not 100% compatbile. >>> >>> For people who do not want the changes we can use the 2.8.x branch. So we >>> could keep porting back some improvements like Dan did for people who >>> want >>> to stay 100% compatible. >>> >>> Christian >>> >>> >>> Am 23.09.2011 16:43, schrieb Christian Schneider: >>>> >>>> Basically that is a good idea. I also thought about a similar solution. >>>> I >>>> would only not like to call it milestone as that typically implies that >>>> it >>>> is instable. No sane admin will deploy a milestone release in >>>> production. >>>> How about 3.0.0-compat or similar. So we could have one or more releases >>>> of this that are fully production ready but will still contain the >>>> @Deprecated classes. Then we can release Camel 3.0.0 that simply removes >>>> these. >>>> >>>> Christian >>>> >>>> Am 23.09.2011 15:59, schrieb Willem Jiang: >>>>> >>>>> I think the main concern of Christian is he afraid Camel 3.0 won't have >>>>> much user to use, and he explain us the recent back ports of Camel >>>>> 2.8.2 is >>>>> because of the API change in Camel 2.9-SNAPSHOT. >>>>> >>>>> How about we treat the Camel 2.9 as the Camel 3.0-m1. When we developed >>>>> Camel 2.0, we actual did three mile stone release to fill the gap of >>>>> the API >>>>> change. >>>>> For the user who want to do some release just after Camel 3.0 RC is >>>>> out, >>>>> he can keep using Camel 3.0 mile stone release. >>>>> For the user who just want use the stable Camel 2.x, he can chose Camel >>>>> 2.8.x, as we already did a lot of merge of on the Camel 2.8.x branch. >>>>> >>>>> Camel 3.0 Mx can tell the user what API change will be made, and we can >>>>> removed the @Deprecates API when the Camel 3.0 is shaped. >>>>> >>>>> Any thoughts ? >>>> >>> >>> >>> -- >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> Talend Application Integration Division http://www.talend.com >>> >>> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
