You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Müller <ch...@gmail.com> on 2012/11/17 14:36:46 UTC
[DISCUSS] determining our Camel release dates in JIRA in advance
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
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Christian Müller <ch...@gmail.com>.
> I don't think its a good idea announce a specific day in advanced,
> which we wont make anyway.
>
A concrete date would be too specific. What's about a month?
Camel 2.9.5 -> Dez. 2012
Camel 2.10.4 -> Jan. 2013
Camel 2.11.0 -> Jan. 2013
We have some conceivabilities about the next release dates. Why not sharing
it with the community? Ppl asking "When we will see Camel y.x.z?" and I
don't see any reason why we should not share our conceivabilities. I would
like this more than a statement like "We will release it, when we finished
it.".
Best,
Christian
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Daniel Kulp <dk...@apache.org>.
On Nov 23, 2012, at 2:16 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Thu, Nov 22, 2012 at 10:24 PM, Christian Müller
> <ch...@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 <hz...@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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Nov 22, 2012 at 10:24 PM, Christian Müller
<ch...@gmail.com> wrote:
> I suppose we have a silence consensus here to announce the releases in
> advance. So far so good...
>
Not really. I think people expressed that their favored more what we do now.
I am not really sure we have consensus.
Though I may have misunderstood what people typed and meant.
> 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.
> 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.
I would rather do what we do today. Where we cut a release and *then*
announce the release when its done.
And when we start cutting a release we say this in public in the
[DISCUSS] mailing lists. Or ppl tweet about this.
So ppl can follow that a new release is on the way.
And Camel 2.11 is not in a state that it can be ready so soon. It
takes longer time. So I dont think we can make it so early in January.
If we are lucky then its ready at the end of January IMHO.
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
Karaf releases in 2012 = 5
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 <hz...@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
>>>
>>>
>
>
> --
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Christian Müller <ch...@gmail.com>.
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 <hz...@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
>>
>>
--
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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
>
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Łukasz Dywicki <lu...@code-house.org>.
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
Re: [DISCUSS] determining our Camel release dates in JIRA in advance
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I think the current model is fine.
If you look at other projects they don't release minor releases more
quickly than we do.
Having the current scheduled with a patch release every 4-6 weeks is good.
Then bug fixes gets into a stable branch in timely manner, and allow
people to upgrade easily (fairly easy).
You do not see Mule, Spring, Karaf, CXF, ActiveMQ, ServiceMix, etc
doing quicker releases than we do.
Though CXF is good at cutting patch releases. But minor releases is
not that much quicker.
Apache CXF 2.5.0 = Oct 2011
Apache CXF 2.6.0 = Apr 2012
Apache CXF 2.7.0 = Oct 2012
Camel 2.10.0 = June 2012
Camel 2.9.0 = Dec 2011
Camel 2.8.0 = Jul 2011
It's a lot of work to maintain and support releases. With the current
model of having trunk + 2 last minor releases supported
with patch releases is a good "middle ground" that the current Camel
team can manage to support and release.
I am fine with discussing and trying to announce that we want to cut
and release Camel x.y.z in about X given date in the future.
This is almost what we do today, with a [DICUSS] thread where we talk
about "its due time" to cut a new release.
I think you have a bad timing about the release dates proposed, as
they are during x-mas time. There is often a zillion things
you need to attend to with family, and also end of year cut-off stuff
at work etc. And then holiday etc.
Also people in the community don't have the luxury of taking up extra
time to give the RC a test spin.
I would suggest to taget Camel 2.10.3 as a December release, or as
soon as possible. I think its stable as is.
And there may not be any outstanding issues. Its IMHO more important
to get this out, so it can be used for SMX 4.5.0, which is their
selected Camel release.
Then a Camel 2.11 as a 2nd priority. Maybe defer that to January, to
allow proper attention to this release.
On Sat, Nov 17, 2012 at 2:36 PM, Christian Müller
<ch...@gmail.com> 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
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen