Hi, I doesn't have the feeling we finished the discussion "Camel 2 8 2 Reason for the many backports" here [1]. So, please participate in this discussion and share your opinions.
My goal is to document the rules for backports for all committers (especially for the new ones) here [2]. I like Claus idea to have a question about this in the next survey, but I think this is not done in short time (I don't know how to do it). Until we know what (most of) our users want, I propose the following rules: - Dependency upgrade in micro version number (e.g. 1.0.0 to 1.0.2) -> YES - Dependency upgrade in minor version number (e.g. 1.0.0 to 1.1.0) -> NO -> For such kind of change, we had also to make sure the dependent library didn't change the API or behavior in the parts the user can configure (in Spring) and refer to it in the URI with (or without) the # symbol. I think we cannot ensure this each time. - Dependency upgrade in major version number (e.g. 1.0.0 to 2.0.0) -> NO - Bug fix which didn't change the API or behavior -> YES - Bug fix which change the API or behavior -> NO -> Document the issue on the known issues section on the release notes - Improvement which didn't change the API or behavior -> MAY BE -> We should discuss such kind of backports before. I would prefer NOT to backport such kind of change (e.g. improvement in an existing component). If there is a real need to backport it and we can make sure it cannot break existing code (e.g. really small change), we can do it exceptionally. - Improvement which changes the API or behavior -> NO - New feature which didn't change the API or behavior -> MAY BE -> We should discuss such kind of backports before. If it cannot break existing code (e.g. it's a new component), why not. Otherwise I would prefer NOT to backport such kind of change (e.g. new feature in an existing component). - New feature which change the API or behavior -> NO - Refactoring -> MAY BE -> We should discuss such kind of backports before. I would prefer NOT to backport bigger refactorings. For small refactoring which are needed for further backports it could be acceptable. Best, Christian [1] http://camel.465427.n5.nabble.com/Camel-2-8-2-Reason-for-the-many-backports-td4821501.html [2] http://camel.apache.org/merging-commits-from-trunk-to-fixes-branch.html
