On Nov 23, 2012, at 2:16 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> On Thu, Nov 22, 2012 at 10:24 PM, Christian Müller > <christian.muel...@gmail.com> wrote: > 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. I definitely think getting something setup to support versions for about 18months makes a lot of sense if we can get there somehow. A lot of companies really just "upgrade" versions once a year or so. Having something that is supported for that year plus the during the dev/test process would make a lot of sense. >> 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. Right. CXF pretty much just says "every 6 months for minor releases, about every 8 weeks for patches." No solid dates or anything. Part of that is due to things always coming up like waiting for 3rd party deps to be released, security bugs to be tracked down, etc…. Usually, when it's close to those timeframes, a quick note to dev@cxf stating "we're close to a release, let me know if you have anything outstanding" is enough to get a feel for when it will happen. > 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 CXF will likely have 3 more next week. :-) Waiting for some updates for wss4j. > Karaf releases in 2012 = 5 Well, Karaf SHOULD have had more… but that's a different topic. :-) Dan > 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 >>>> >>>> >> >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
