camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Camel 2.8.2 - Reason for the many backports?
Date Sat, 24 Sep 2011 18:32:41 GMT
Excellent points Christian. My take on this inline.


On 09/24/2011 01:34 PM, Christian Müller wrote:
> Hello Claus!
> Thank you for your work updating the WIKI page. I didn't know them...
> But I have to "stress" this topic a bit more, because I still have open
> questions:
> 1) Is it a problem when different committers use different merge tools (the
> Java program, the Python script, simply Git, ...)?
Probably not. The result it what matters. As long as the tool does the 
job everybody should use what he's comfortable with, unless there is a 
very good reason not to (don't see one in this case).

> 2) What is our policy about backporting issues (only bugs, dependency
> upgrades for bug fix versions, improvements, new features, dependency
> upgrades which are not bug fix versions, ...)?
I think we should backport as much as possible and give our users the 
best experience possible on any supported branch as long as:
* we have 100% backward compatibility on patch versions (3rd digit). 
Dependencies versions may be upgraded to include fixed bugs, but 
probably not to a major release
* almost 100% compatibility on minor releases. Simple, straightforward 
migration steps if at all.

> 3) Still not clear why we backport many issues to 2.8.2 and not to 2.7.4.
We should backport as much as we can to 2.7.x while it is maintained. I 
think it's just a matter of finding the time to do it.

> I stess this to make it clear for everybody, document it and to provide a
> better mentoring for new committers.
Yes, by all means we should document that. It'll be helpful to both 
committers and users at large who would know what to expect.

> Christian
> Sent from a mobile device

View raw message