camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
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
<christian.mueller@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message