Figured I should respond to this important email... though maybe we have lazy consensus on the topic? ;)
I think in general this makes a lot of sense and really, we are following most of this right now anyways. And of course, these are not hard and fast rules and we can always DISCUSS later for specific exemptions when the need arises... comments inline... On Sun, Oct 16, 2011 at 12:14 PM, Christian Müller < christian.muel...@gmail.com> wrote: > 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. > Yeah, extra checking would be good for this case but I guess in a micro version release there should be no API changes. > - 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. > Sometimes an improvement to an existing component will just be adding a new option to a URI for example. I think this is okay as long as existing option defaults remain the same. > - 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). > +1 I'd prefer not to do this as well since we want folks to have a reason to upgrade to the newer versions. > - 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. > Yeah, we'd have to be pretty careful about this one for sure. I guess 2.9 vs. 2.8.x is the perfect example of this case. I'm pretty sure we decided to keep all refactorings on trunk rather than backport... > > 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 > -- Cheers, Jon --------------- FuseSource Email: j...@fusesource.com Web: fusesource.com Twitter: jon_anstey Blog: http://janstey.blogspot.com Author of Camel in Action: http://manning.com/ibsen
