...

Broker will do the followings for log retention during migration:

1. The broker will rebuild a the time based log index for each segment if the segment does not have a time index.
   1. If the message.format.version of a topic is before 0.10.0, the time index will only have one entry (last_modification_time_of_the_segment -> offset_of_the_last_message_in_the_segment)
   2. If the message.format.version of a topic is on 0.10.0, the broker will scan the messages in a log segment and rebuild the timestamp, if . If no message has a timestamp in the segment, the entry (last_modification_time_of_the_segment -> offset_of_the_last_message_in_the_segment) will be inserted to the log index. Otherwise the time index will be built in the normal way.
2. After the entire cluster is migrated to use time based log index for log retention. The broker will enforce log retention using time index. Given what we do in step 1, the behavior is:
   1. For segments only has messages whose versions are before 0.10.0, the entry with last modification time in the time index will be used for retention.
   2. For segments has at least one message whose version is after 0.10.0, the max timestamp of the messages will be used for log retention.

Broker will do the followings for log rolling during migration.

1. Broker On startup, broker will initially use the segment last modification time as the max message timestamp.
2. If a new message whose version is after 0.10.0 and its timestamp is greater than current max message timestamp. The broker updates the current max message timestamp.
3. Broker always use the difference between current time and max message timestamp to decide whether roll out a new log segment or not.

...

Rejected Alternatives

Add a timestamp field to log index entry

...