camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Date Tue, 20 Nov 2012 16:57:58 GMT
I really like the idea of having major releases more often. It makes transition between releases
faster and easier, even for users.

There was a talk few months ago about git usage in camel (instead of svn) few months ago:
http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-td5715773.html

I believe that usage of proper git branching model will make maintenance of multiple branches
easier and prevent us from running micro release every two weeks.


Wiadomość napisana przez Christian Müller w dniu 17 lis 2012, o godz. 14:36:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message