Merge order for commits to older versions?

[Koen De Groote <kd...@gmail.com>]

Greetings,

I recently created a minor PR for trunk and realized I should probably put
it on 0.11.0, assuming a release of 0.11.x eventually gets merged into
trunk.

But looking at the GitHub branches, I found that 0.11.0 is ahead of trunk
by 404 commits, which seems rather a large difference:
https://github.com/apache/kafka/tree/0.11.0

What exactly is the policy of commits added to older versions?


Suppose a version 0.11.0.3 would come out, based on changes on 0.11.0 since
0.11.0.2, would 0.11.0 then be merged onto trunk? I would expect it, but it
looks like that's not the case. Am I mistaken?

I looked around a bit but couldn't find a document stating the policy on
this.

I was reminded of reading the contrib guidelines for Cassandra, another
Apache project. Which had this on its page:
http://cassandra.apache.org/doc/latest/development/patches.html#choosing-the-right-branches-to-work-on

Which clearly states that older version X is only to receive bugfixes,
really old version Y only receives critical bug fixes, etc...

Is there a document detailing this policy for Kafka? If there is, I
probably overlooked it. If so, where should I have found it?

Kind regards,
Koen De Groote

Re: Merge order for commits to older versions?

[Koen De Groote <kd...@gmail.com>]

Hello Matthias,

Thanks, that makes perfect sense. I'm just used to a different system, but
what you described works fine too.

Now that I understand the system, I see that the PR isn't needed on 0.11.x.
and can just go on trunk.

Thanks for your time.

On Sat, May 19, 2018 at 8:31 PM, Matthias J. Sax <ma...@confluent.io>
wrote:

> Hi,
>
> not sure if this is documented in the wiki on not (feel free to add it
> to the wiki :)). It works as follows:
>
> Older version branches are only used for bug fix releases and are never
> merged into trunk. All PRs are opened against trunk by default and if we
> want to get a commit into an older branch to add it to a bug fix
> release, the commit gets cherry-picked if possible. If cherry-picking
> does not work because code changed too much, a new PR against the old
> version branch would be made to manually back port the fix based on the
> old code.
>
> Does this make sense?
>
> If you did a recent minor PR and think it should be back ported to
> 1.1.0, 1.0.0, and 0.11.0 just put a comment on the PR and ask the
> committer who merged it, if it makes sense to cherry-pick to older
> branches.
>
> Hope this helps. :)
>
>
> -Matthias
>
> On 5/19/18 3:26 AM, Koen De Groote wrote:
> > Greetings,
> >
> > I recently created a minor PR for trunk and realized I should probably
> put
> > it on 0.11.0, assuming a release of 0.11.x eventually gets merged into
> > trunk.
> >
> > But looking at the GitHub branches, I found that 0.11.0 is ahead of trunk
> > by 404 commits, which seems rather a large difference:
> > https://github.com/apache/kafka/tree/0.11.0
> >
> > What exactly is the policy of commits added to older versions?
> >
> >
> > Suppose a version 0.11.0.3 would come out, based on changes on 0.11.0
> since
> > 0.11.0.2, would 0.11.0 then be merged onto trunk? I would expect it, but
> it
> > looks like that's not the case. Am I mistaken?
> >
> > I looked around a bit but couldn't find a document stating the policy on
> > this.
> >
> > I was reminded of reading the contrib guidelines for Cassandra, another
> > Apache project. Which had this on its page:
> > http://cassandra.apache.org/doc/latest/development/
> patches.html#choosing-the-right-branches-to-work-on
> >
> > Which clearly states that older version X is only to receive bugfixes,
> > really old version Y only receives critical bug fixes, etc...
> >
> > Is there a document detailing this policy for Kafka? If there is, I
> > probably overlooked it. If so, where should I have found it?
> >
> > Kind regards,
> > Koen De Groote
> >
>
>

Re: Merge order for commits to older versions?

["Matthias J. Sax" <ma...@confluent.io>]

Hi,

not sure if this is documented in the wiki on not (feel free to add it
to the wiki :)). It works as follows:

Older version branches are only used for bug fix releases and are never
merged into trunk. All PRs are opened against trunk by default and if we
want to get a commit into an older branch to add it to a bug fix
release, the commit gets cherry-picked if possible. If cherry-picking
does not work because code changed too much, a new PR against the old
version branch would be made to manually back port the fix based on the
old code.

Does this make sense?

If you did a recent minor PR and think it should be back ported to
1.1.0, 1.0.0, and 0.11.0 just put a comment on the PR and ask the
committer who merged it, if it makes sense to cherry-pick to older branches.

Hope this helps. :)


-Matthias

On 5/19/18 3:26 AM, Koen De Groote wrote:
> Greetings,
> 
> I recently created a minor PR for trunk and realized I should probably put
> it on 0.11.0, assuming a release of 0.11.x eventually gets merged into
> trunk.
> 
> But looking at the GitHub branches, I found that 0.11.0 is ahead of trunk
> by 404 commits, which seems rather a large difference:
> https://github.com/apache/kafka/tree/0.11.0
> 
> What exactly is the policy of commits added to older versions?
> 
> 
> Suppose a version 0.11.0.3 would come out, based on changes on 0.11.0 since
> 0.11.0.2, would 0.11.0 then be merged onto trunk? I would expect it, but it
> looks like that's not the case. Am I mistaken?
> 
> I looked around a bit but couldn't find a document stating the policy on
> this.
> 
> I was reminded of reading the contrib guidelines for Cassandra, another
> Apache project. Which had this on its page:
> http://cassandra.apache.org/doc/latest/development/patches.html#choosing-the-right-branches-to-work-on
> 
> Which clearly states that older version X is only to receive bugfixes,
> really old version Y only receives critical bug fixes, etc...
> 
> Is there a document detailing this policy for Kafka? If there is, I
> probably overlooked it. If so, where should I have found it?
> 
> Kind regards,
> Koen De Groote
>