On Thu, Nov 22, 2012 at 10:24 PM, Christian Müller <christian.muel...@gmail.com> wrote: > I suppose we have a silence consensus here to announce the releases in > advance. So far so good... >
Not really. I think people expressed that their favored more what we do now. I am not really sure we have consensus. Though I may have misunderstood what people typed and meant. > The advantage for me to have a new minor release every 3 - 4 month is: > - the earlier availability of changes which are not backwards compatible. > But to be honest, I don't think we have much of them. > > The advantage for me to have a new minor release every 6 month is: > - we support a version for 18 month (the last two minor releases) instead > of only 9 -12 month. > I am not sure we reach as far as 18 months. For example for Camel 2.9.x that is likely more 12-14 months. > In both cases: > - we could ship planned micro/patch releases every 4 - 6 weeks (maybe each > month is easier to remember). > > What's with the following proposal: > - Camel 2.9.5/2.10.3 -> 09.12.2012 > - Camel 2.11.0 -> 06.01.2013 > - Camel 2.9.6/2.10.4 -> 13.01.2013 (this is the past planned 2.9.x release) > I don't think its a good idea announce a specific day in advanced, which we wont make anyway. And also its not a habit that our peek OS projects do; I dont see a news bullet on the CXF website, saying that CXF 2.7.1 is being released on 06.01.2013 etc. I would rather do what we do today. Where we cut a release and *then* announce the release when its done. And when we start cutting a release we say this in public in the [DISCUSS] mailing lists. Or ppl tweet about this. So ppl can follow that a new release is on the way. And Camel 2.11 is not in a state that it can be ready so soon. It takes longer time. So I dont think we can make it so early in January. If we are lucky then its ready at the end of January IMHO. And I dont think we can release a patch release of 2.10.4 so soon. You are overlapping the x-mas holidays. So there hasn't been much activity that warrants us cutting a new patch release. IMHO a 2.10.4 release is more likely at the end of January. I just took a quick look in Maven Central to see number of releases this year. Camel releases in 2012 = 8 (counting 2.9.0 as 2012 as it was 31-dec-2011 just 2h before midnight) CXF releases in 2012 = 10 Karaf releases in 2012 = 5 IMHO we have the right balance currently with the frequency of releases we can manage. Expecting 2 more releases for 2.10 and 2.9 patches to come out this year. > Best, > Christian > > On Wed, Nov 21, 2012 at 2:22 AM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > >> We did not try to release every 3 months after we started to issue patch >> releases. I agree with Claus that what we have now is a better model, and I >> prefer it as well. >> >> That said, I agree the release cycle should be more predictable and >> announced in advance. I like for instance the Ubuntu model with releases in >> Apr and Oct. We could have something similar for minor releases, like odd >> ones in March and even ones in Sep (or whatever the months are gonna be). >> >> Maybe we could throw a few proposals out there and agree on one? >> >> My $0.02, >> Hadrian >> >> >> >> >> On 11/17/2012 08:36 AM, Christian Müller 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
