Versioning scheme

[jpallari]

The versioning scheme described in the README didn't work out quite as well as I had hoped. The current version scheme assumes that the first two parts of the version are dedicated for Kafka compatibility while the rest of the parts describe SKC versioning. Since the Kafka project decided to make additional incompatible changes in 0.10.1, we'd have to track the extra third part of the version.

Figure out a versioning scheme for SKC that tracks both Kafka compatibility and the client compatibility.

[jpallari]

As an example, we could use a versioning scheme like this:

$MAJOR.$MINOR.$PATCH-k$KAFKA

where:

• MAJOR, MINOR, and PATCH describe the SKC versioning
• KAFKA describes the Kafka compatible version

Examples:

1.2.3-k0.9     => compatible with Kafka 0.9
1.2.3-k0.10    => compatible with Kafka 0.10
1.2.3-k0.10.1  => compatible with Kafka 0.10.1

Note that JARs use lexicographical ordering after the dash, so -k0.9 takes precedence over -k0.10. This could be solved by naming 0.9 compatible version as -k0.09 instead. However, if you ever run into a situation where you pull dependencies for multiple Kafka versions, you should probably standardise to a single Kafka version anyhow.

[jpallari]

I think we also need to figure out how far are we going to extend Kafka support.