Re: [DISCUSS] Rules for backports

[Jon Anstey <ja...@gmail.com>]

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.mueller@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: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: [DISCUSS] Rules for backports

[Christian Müller <ch...@gmail.com>]

Hello Dan!

Thanks for your contribution. I like it...

Best,
Christian

Sent from a mobile device

Re: [DISCUSS] Rules for backports

[Daniel Kulp <dk...@apache.org>]

I just fixed a few minor grammatical things and added more into the "who" 
section. 

Dan


On Sunday, November 20, 2011 9:25:03 PM Christian Müller wrote:
> Today, I had some time to work on it and update [1].
> Please review this change and feel free to update/ask/discuss the changes
> you do not understand/agree with/...
> 
> I hope we reached consensus here.
> 
> [1]
> https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk
> +to+fixes+branch
> 
> Best,
> Christian
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: [DISCUSS] Rules for backports

[Christian Müller <ch...@gmail.com>]

Today, I had some time to work on it and update [1].
Please review this change and feel free to update/ask/discuss the changes
you do not understand/agree with/...

I hope we reached consensus here.

[1]
https://cwiki.apache.org/confluence/display/CAMEL/Merging+commits+from+trunk+to+fixes+branch

Best,
Christian

Re: [DISCUSS] Rules for backports

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

It sounds good,

Thanks Christian

Regards
JB

On 11/12/2011 07:29 AM, Christian Müller wrote:
> I will put these things together and put it into our WIKI in the next few
> days. Feel free to comment, if you disagree with a point and didn't raise
> your voice until now.
>
> Best,
> Christian
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Rules for backports

[Christian Müller <ch...@gmail.com>]

I will put these things together and put it into our WIKI in the next few
days. Feel free to comment, if you disagree with a point and didn't raise
your voice until now.

Best,
Christian