Hi I think the current model is fine.
If you look at other projects they don't release minor releases more quickly than we do. Having the current scheduled with a patch release every 4-6 weeks is good. Then bug fixes gets into a stable branch in timely manner, and allow people to upgrade easily (fairly easy). You do not see Mule, Spring, Karaf, CXF, ActiveMQ, ServiceMix, etc doing quicker releases than we do. Though CXF is good at cutting patch releases. But minor releases is not that much quicker. Apache CXF 2.5.0 = Oct 2011 Apache CXF 2.6.0 = Apr 2012 Apache CXF 2.7.0 = Oct 2012 Camel 2.10.0 = June 2012 Camel 2.9.0 = Dec 2011 Camel 2.8.0 = Jul 2011 It's a lot of work to maintain and support releases. With the current model of having trunk + 2 last minor releases supported with patch releases is a good "middle ground" that the current Camel team can manage to support and release. I am fine with discussing and trying to announce that we want to cut and release Camel x.y.z in about X given date in the future. This is almost what we do today, with a [DICUSS] thread where we talk about "its due time" to cut a new release. I think you have a bad timing about the release dates proposed, as they are during x-mas time. There is often a zillion things you need to attend to with family, and also end of year cut-off stuff at work etc. And then holiday etc. Also people in the community don't have the luxury of taking up extra time to give the RC a test spin. I would suggest to taget Camel 2.10.3 as a December release, or as soon as possible. I think its stable as is. And there may not be any outstanding issues. Its IMHO more important to get this out, so it can be used for SMX 4.5.0, which is their selected Camel release. Then a Camel 2.11 as a 2nd priority. Maybe defer that to January, to allow proper attention to this release. On Sat, Nov 17, 2012 at 2:36 PM, Christian Müller <christian.muel...@gmail.com> wrote: > What's your opinion about determining our next Camel release dates in JIRA > in advance? > I think this could help us to synchronize our planning (from each > committer). It will also help us to work more in the RERO (release early - > release often) mode because it makes it more difficult to miss a release > date. I think this was the case a few times in the past, especially if we > have to deal with some overload (in our business or in our private). Let me > share some examples. Normally we try to ship a new minor release each 3 > month: > Camel 2.0.0 (08/2009) > Camel 2.1.0 (12/2009) -> after 4 month (fixed 308 issues) > Camel 2.2.0 (02/2010) -> after 2 month (fixed 181 issues) > Camel 2.3.0 (05/2010) -> after 3 month (fixed 277 issues) > Camel 2.4.0 (07/2010) -> after 2 month (fixed 184 issues) > Camel 2.5.0 (10/2010) -> after 3 month (fixed 301 issues) > Camel 2.6.0 (01/2011) -> after 3 month (fixed 295 issues) > Camel 2.7.0 (03/2011) -> after 2 month (fixed 170 issues) > Camel 2.8.0 (05/2011) -> after 2 month (fixed 423 issues) > Camel 2.9.0 (12/2011) -> after 7 month (fixed 498 issues) > Camel 2.10.0 (07/2012) -> after 7 month (fixed 492 issues) > Camel 2.11.0 (?) -> after 4+ month (fixed 300+ issues) > > One of the reasons why the last two releases was released after a much more > longer time is, that we started to backport fixes into the two maintenance > branches - which is a good thing. But this should not prevent us to release > a new minor version each 3 month IMO. > > I propose targeting the following release dates: > Camel 2.11.0 -> 12/16/2012 > Camel 2.10.3 -> 12/23/2012 > Camel 2.9.5 -> 12/23/2012 (last regular 2.9.x release) > Camel 2.12.0 -> that's another discussion I will start soon > Camel 3.0.0 -> that's another discussion I will start soon > > The determining release date is not a fix date, it's a planned release date > which we may post pone if we have some difficulties with the release or > some last minute critical bugs we have to fix. But we should of course try > to target the planned release date. > > Our users also benefit from this because they can better plan when they can > expect (round about) a new Camel version. > > Have a nice weekend, > Christian -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
