camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Date Wed, 21 Nov 2012 01:22:57 GMT
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
>

Mime
View raw message