May it was not the best idea to call this thread "[DISCUSS] Rules for Backports". What I had in mind was more like "[DISCUSS] Guidelines for Backports". Also my *NO* for some backports seems to be strong, but not for all... Because we had a few discussions/questions in the last weeks about some backports (which shows to me we had different understandings how it should work) and I didn't found any guideline/reference on the ASF sites, I thought and still think it's a good idea to discuss these different preferences and come out of this discussion with something like a guideline. And I also think this guideline will be useful for our new committers to follow our development guidelines... And by the way, I also don't want to change our CTR model [1] to a RTC model [2]...
I think the backports we are discussing are: - Dependency upgrade in minor/major version number - Improvement which didn't change the API or behavior - New feature which didn't change the API or behavior Claus proposal in a private conversation was to have at least a [HEADS UP] for such kind of change which are not trivial, big or edge cases. Then all developers have the change to express their fears if there are ones. I think this is a good balance to make sure we release really stable maintenance releases for our users and give them in the same time all the improvements and new features from trunk *IF* they doesn't change the API or behavior. [1] http://apache.org/foundation/glossary.html#CommitThenReview [2] http://apache.org/foundation/glossary.html#ReviewThenCommit Best, Christian On Sun, Oct 16, 2011 at 9: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. > - 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
