camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 2.8.2 - Reason for the many backports?
Date Mon, 03 Oct 2011 06:39:09 GMT
On Tue, Sep 27, 2011 at 7:18 PM, Christian Müller
<> wrote:
> I updated [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
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message