Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call for discussion - Does anyone use the 0.8.0 or 0.8.2 implementations? #260

Open
dantswain opened this issue Dec 5, 2017 · 5 comments

Comments

@dantswain
Copy link
Collaborator

We maintainers are discussing dropping the 0.8.0 and 0.8.2 client implementations.

Does anyone in the community use these implementations or is everyone using the 0.9.0 implementation?

Note that existing versions of the package on hex.pm would still support 0.8.0 and 0.8.2, we would just be removing them going forward.

Feedback is appreciated!

@joshuawscott
Copy link
Member

As long as we are going to a new major version, I'd be in favor of dropping those, especially if it will make it easier to get the protocol implementation flexible enough to match the specifications for 0.9, 0.10, 0.11, 1.0 etc.

@wilbertom
Copy link

@dantswain we had some conversations about an older version of Kafka so here are my two cents.

In production environments in bigger companies, we sometimes don't control what versions of a software are used. Upgrading takes a huge organizational effort to upgrade all dependent components.

That said I think your comment on older versions of the library supporting the older versions of Kafka are a great point. If someone needs support, they can just install an older version. These shouldn't updated unless one has to take a patch for security reasons.

What would be really helpful though would be a Changelog, where one could easily see when features were implemented and older things deprecated. This would be very helpful in general and people would have an easier time picking the appropriate version.

Personally I'm all up for deleting old code, cleaning and pruning the versions that matter most in the long run. It also makes it easier for new people interested in contributing to the project, they can read just the newer implementations and not be taunted or distracted by the older implementations.

@thecodeboss
Copy link
Contributor

thecodeboss commented Feb 6, 2018

Bit late to the party, but I will add that our infrastructure still relies on Kafka 0.8.1.1 quite a bit. There have been some efforts recently to upgrade, though as @wilbertom mentioned that sort of upgrade is difficult.

Saying that, I'm okay with dropping support for future versions - I can always fork to try and get any fixes if necessary.

EDIT: I'm told by our logging team that they have been upgrading our Kafka fleet recently, which should be done within the next couple weeks. So looks like we won't be on 0.8.1.1 for much longer.

@IanVaughan
Copy link
Contributor

It would help me a lot, as I have some changes that I've only made in 0.9 server module at present, so if it's deprecated then I can hold off thinking about updating the other server version modules.

@IanVaughan
Copy link
Contributor

How would this be best done? Completely remove the < 0.9 server modules? Or phase it, so initially add some form of depreciation warning if the kafka_version is less than 0.9?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants