Hello, I am just a humble camel user who also develop some custom add-ons and components (will post about that later when I finally get some time..)
While Apache should not take the place of supporting companies like FuseSource (who rolls their own releases with cherry picked patches) I tend to agree with Hadrian that Camel should contemplate being (at least) *open* for patch-releases. Because as it is now, if I find a problem now, that you have a fix for I can do a couple of things: 1) roll my own relase with back port of the fix. 2) work around the issue more or less beautifully 3) wait for next camel release all course have some drawbacks, but i suspect most would use §2 until §3 happens. but as the development of camel is progressing quite rapidly, new behavior, components and dependencies are introduced all the time. For many of us, there is not always an option to just swap camel version. If say, you have a system in production that is working well, except that you need to introduce new use cases or integrations without risking everything else. Having a bug fix release branch that some fixes are back-ported to, would also ease the "progression rate anxiety" of the Camel committers too, perhaps (if they care about their users' problems) Of course, I see the problems with committer workload, configuration management and qa, etc being there myself so I'm not really complaining, just chiming in :-) (and using hand rolled patches) /Björn On Thu, Dec 16, 2010 at 11:21 AM, Guillaume Nodet <[email protected]> wrote: > The good news is that we've found a workaround in ServiceMix so we > don't need a minor release anymore :-) > I think keeping our current 3 months release cycle as it has proven to > work very well those last years. > > On Wed, Dec 15, 2010 at 19:33, Hadrian Zbarcea <[email protected]> wrote: >> Hi Willem, >> >> Personally I am in favor it and I could start the release builds >> immediately. However: >> 1. There is no camel-2.5.1 branch so one would have to be created. We could >> create a camel-2.5 branch off of the 2.5.0 tag. >> 2. There is no precedent for having patch releases in Camel (3rd digit). It >> doesn't mean we cannot start it (I would like that actually) but we need to >> discuss it and agree on something >> 3. If we do that it would make sense to have more formal support cycle for a >> version. Camel imho got a maturity level that almost requires it. >> >> My preference would be a 6 weeks release cycle, meaning 2 releases per >> quarter. Patch releases should be 100% backwards compatible (including dsl), >> no version upgrades for dependencies and should only include bug fixes. >> Minor releases (2nd digit) could bring new features, components, dependency >> upgrades (as we do it now). Major releases will be rare, but 3.0 is coming >> up. >> >> Thoughts/ideas/preferences? >> Hadrian >> >> On Dec 15, 2010, at 9:30 AM, Willem Jiang wrote: >> >>> Hi, >>> >>> I just found some issues[1][2] of camel-cxf in Camel 2.5.0 which cause the >>> camel-nmr component tests[3] failed. I didn't find a way to work round the >>> camel issues without changing the code camel. >>> >>> As you know ServiceMix 4.3.0 releasing is on the way, if we let ServiceMix >>> pick up the latest Camel 2.6.0, there will be not just waiting for the >>> Camel 2.6.0 release issue. ServiceMix also need to upgrade it's CXF version >>> to 2.3.x and prepare the bunch of new JAXWS, JAXRS bundle release. >>> >>> Now I propose to do Camel 2.5.1 release myself by merging the upper camel >>> fix into 2.5 branch, In this way, we can fix the camel-nmr issue without >>> blocking the ServiceMix 4.3.0 release. >>> >>> Any thoughts ? >>> >>> [1]https://issues.apache.org/jira/browse/CAMEL-3426 >>> [2]https://issues.apache.org/jira/browse/CAMEL-3431 >>> [3]https://issues.apache.org/jira/browse/SMX4-707 >>> >>> -- >>> Willem >>> ---------------------------------- >>> FuseSource >>> Web: http://www.fusesource.com >>> Blog: http://willemjiang.blogspot.com (English) >>> http://jnn.javaeye.com (Chinese) >>> Twitter: willemjiang >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
