I suppose we have a silence consensus here to announce the releases in advance. So far so good...
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. 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) 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 >> >> --
