On Sat, Sep 24, 2011 at 8:32 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > Excellent points Christian. My take on this inline. > > Hadrian > > 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 to agree if its a *patch* release or if its not a patch release. A patch release is supposed to be a 100% drop-in replacement to fix some major bugs / security vulnerabilities. A very low-risk upgrade, with just enough changes, and nothing more. Better to be conservative and omit a commit, than to include it, if you are in doubt. > * we have 100% backward compatibility on patch versions (3rd digit). We do not have that for 2.8.2. There is API changes. There is new features backported, which risk introducing new bugs. There is problem keeping documentation up to date, when backporting new features, as you would have to remember to update the documentation as well. Which wasn't the case for 2.8.2. This will of course get better if the documentation was part of the SVN. > 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. > And this is *certainly* not the case for Camel 2.9. But we are already debating this in another thread. >> 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 >> > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
