RFC: Supported Kafka and Go Versions

[eapache]

As we approach stricter versioning (aka 1.0) we need a slightly more well-defined process for defining supported versions of kafka and go.

I propose a 2+2 model for both: we support the 2 most recent versions, with a 2 month grace period for older releases. For example, we currently support go 1.4 and 1.3 as the two most recent stable releases, and we support 1.2 for at least two months after the initial release of 1.4 (FWIW, those two months are now passed, so in this model we'd now be justified in dropping support for go 1.2).

For kafka, this means we support 0.8.2 and 0.8.1, and that we'd continue (nominal) support for 0.8.0 until April 4th, two months after the release of 0.8.2.

Of course this doesn't mean we'd gratuitously break support for old versions, just that we wouldn't test against them or make a particular effort to be compatible.

Thoughts @Shopify/kafka and anyone else this might affect (e.g. @schleppy)

P.S. if this is acceptable, I'd like to target Sarama 1.0.0 for the beginning of April, just after dropping official support for Go 1.2 and Kafka 0.8.0.

[schleppy]

I like the idea of the 2+2 support. For go it is pretty much a no brainer since 1.x is guaranteed api compatible. For Kafka I am not sure such guarantees exist, so unless you are always willing to be on the latest release (regardless of possible changes and/or bugs) then 2 months might not be enough time. Additionally, it may be hard to target Kafka versions if the protocols change as it could have rippling effects in the code base and maintaining both protocols might be more trouble than it is really worth (a different branch perhaps.)

Anyway, I like the idea - and like more that it is being formally considered.

[yagnik]

+1 to 2+2 support.
Kafka also ensures that api is compatible for at least one previous release so 2 versions makes sense.

I agree with @schleppy that maintaining two protocols might not be worth but I'd still like to formally write this down and adhere to it till the time it becomes an extreme pita to do this.

[wvanbergen]

We basically have to re-evaluate this for Kafka 0.9.0, to see what kind of changes that release will bring and if it is feasible to support 0.8 and 0.9 at the same time. As long as we're dealing with 0.8 releases, 2+2 should work for me.

For stuff like #156, I have no problem making exceptions to this rule if necessary (even though in this case it is not necessary).

I opened #320 to make CI run against different Kafka versions.

[eapache]

OK, I'll leave this ticket open to track documenting this support pattern officially in the README, but I think we're in agreement. We can definitely re-evaluate when 0.9.0 comes out, but Kafka's releases have been much farther apart than Go's, so I expect by the time that happens everybody will be fully on 0.8.2.

[wvanbergen]

Added note to README; closing.