On Tue, Sep 27, 2011 at 7:18 PM, Christian Müller <christian.muel...@gmail.com> wrote: > 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) >
Nice lay out of the items in the bullets above. I am a bit torn in terms of dependency updates, as some ppl may want this, and others want no updates. I can understand a dependency update on the patch level / or even a minor update if there is a justification that it fixes some major issues that the end users suffer. > 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? > That can be a good idea, but the people who speak in the Apache mailing lists, is only the tip of the iceberg of all our end users. And one week is not a very long time. I think an easier way of submitting your comment would be some sort of survey in a web form where you do not need to sign up for a mailing list etc. Maybe we could do a 2nd survey and have questions in relationship to this in the survey, (along with some other questions as well). > 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"? > Yep when the documentation is part of the source code in the SVN, then we can have this resolved. > Looking forward of your comments, > Christian > -- 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/
