...

As mentioned above, as a result of this new semantics, all offsets in a group expire at the same time. The broker config offsets.retention.minutes determines when they expire (after the group becomes Empty). Older clients that prefer to honor their individual retention overrides (through OffsetCommitRequest) will need to set offsets.retention.minutes to the maximum of those overrides and the value of offsets.retention.minutes. This simply guarantees that the offsets will not expire any earlier now with the new semantics (because the expiration clock for a partition now starts no earlier - and perhaps later - than before). This also simplifies handling of clients that use different versions of the API.

Backward and forward compatibility of OffsetCommit API:

...

For old clients that send an OffsetCommitRequest of version 3 or earlier

...

, any custom partition-level retention will be ignored, and instead the broker level retention of offsets.retention.minutes will apply to determine expiry of all offsets within the group. As discussed above, a high enough offsets.retention.minutes has to be used to guarantee the previous retentions are not negatively impacted. Group offsets expire together

...

.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.