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
