...

Details of the change can be viewed from the pull request.

FAQ

Q) Why use a long to represent the compaction value?

A) By using this format, we can better have a comparable that can be used by the client for both a timestamp version approach or an incremental numeral version approach.

Q) How does the compaction value get parsed from byte[] to long?

A) This is accomplished by first converting the byte[] into an UTF-8 encoded String, and then converting this String to a long. If any of these steps fails, then the compaction value is ignored (ie, its considered the record doesn't have a versioned compaction value).

Q) Why convert from byte[] to String to long instead of just converting directly to long?

A) This is done to keep the Kafka API language agnostic, as the binary representation of String is guaranteed by the used encoding, while the binary representation of long varies according to the client's coding language.

Q) Why not compare the raw byte[] directly instead of performing these conversions?

A) Although the byte[] can be compared, it is not actually comparable. As in, the binary representation of "7" is not necessarily greater than the binary representation of "5" (used for example purposes only, for low numbers these comparisons are actually correct, but they start getting into grey territory once you get some larger numbers).

Compatibility, Deprecation, and Migration Plan

...