camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <christian.muel...@gmail.com>
Subject Re: [DISCUSS] Rules for backports
Date Wed, 19 Oct 2011 18:50:17 GMT
May it was not the best idea to call this thread "[DISCUSS] Rules for
Backports". What I had in mind was more like "[DISCUSS] Guidelines for
Backports". Also my *NO* for some backports seems to be strong, but not for
all...
Because we had a few discussions/questions in the last weeks about some
backports (which shows to me we had different understandings how it should
work) and I didn't found any guideline/reference on the ASF sites, I thought
and still think it's a good idea to discuss these different preferences and
come out of this discussion with something like a guideline. And I also
think this guideline will be useful for our new committers to follow our
development guidelines...
And by the way, I also don't want to change our CTR model [1] to a RTC model
[2]...

I think the backports we are discussing are:
- Dependency upgrade in minor/major version number
- Improvement which didn't change the API or behavior
- New feature which didn't change the API or behavior

Claus proposal in a private conversation was to have at least a [HEADS UP]
for such kind of change which are not trivial, big or edge cases. Then all
developers have the change to express their fears if there are ones. I think
this is a good balance to make sure we release really stable maintenance
releases for our users and give them in the same time all the improvements
and new features from trunk *IF* they doesn't change the API or behavior.

[1] http://apache.org/foundation/glossary.html#CommitThenReview
[2] http://apache.org/foundation/glossary.html#ReviewThenCommit

Best,
Christian

On Sun, Oct 16, 2011 at 9: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.
> - 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.
> - 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).
> - 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.
>
> 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

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