camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Anstey <jans...@gmail.com>
Subject Re: [DISCUSS] Rules for backports
Date Thu, 10 Nov 2011 19:28:01 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message