I updated [Merging commits from trunk to fixes branch| https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch] with the information how to merge with git/git-svn.
At present, I think we do not have a consensus at all, what should be merged into the maintenance branches. I think we have a consensus to merge/back port the following issues: - issues considered as bug - dependency updates on the micro version number (e.g. from 1.0.0 to 1.0.1) I also think we have a consensus to NOT merge/back port the following issues: - any change which changes the Camel API - any change which changes the behavior for the user (other default value, ...) On the following cases, we have different opinions: - dependency updates on the major version number (e.g. from 1.0.0 to 2.0.0) - dependency updates on the minor version number (e.g. from 1.0.0 to 1.1.0) - improvements which NOT changes the API or the behavior (fully backwards compatible) - new features which NOT changes the API or the behavior (fully backwards compatible) I prefer only to back port issues where we already have a consensus. The reason is simply code stability. Each new feature, improvement or dependency update has the risk to introduce a new issue and break the existing code. I could imagine most of the users think in the same way and accept to update to a new major/minor release for improvements or new features. In the rare cases where this is not the case, there are commercial vendors which could fill this gap... But why we don't ask our users and let they decide? I would like to start a public [VOTE] on user@ for one week or so and ask our users what they prefer. What do you think? Another "issue" is how to document the availability of new features without confusing our users. e.g. "from Camel 2.7.4 but not in 2.8.0 and 2.8.1"? Looking forward of your comments, Christian
