Allow google-protobuf 3.8

[luke-hill]

Summary

Allow protobuf 3.8

Details

This allows 3.8, which "should" fix all builds aside from JRuby (According to their maintainers). JRuby is something which isn't fully on their roadmap yet, so we're still on our own for that.

Motivation and Context

Should fix any niggling issues with 2.3-2.6 (Note that 3.8 forces Ruby 2.3, but we're already doing that)

How Has This Been Tested?

CI

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• The change has been ported to Java.
• The change has been ported to Ruby.
• The change has been ported to JavaScript.
• The change has been ported to Go.
• The change has been ported to .NET.
• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[luke-hill]

See protocolbuffers/protobuf#1594 (comment) for more latest updates from protobufs maintainer.

[olleolleolle]

@luke-hill

CircleCI was unable to start the container because of a userns remapping failure in Docker.

This typically means the image contains files with UID/GID values that are higher than Docker and CircleCI can use.

Checkout our docs https://circleci.com/docs/2.0/high-uid-error/ to learn how to fix this problem.
Original error: CircleCI was unable to start the container because of a userns remapping failure in Docker.

This typically means the image contains files with UID/GID values that are higher than Docker and CircleCI can use.

Checkout our docs https://circleci.com/docs/2.0/high-uid-error/ to learn how to fix this problem.
Original error: failed to register layer: Error processing tar file(exit status 1): Container ID 231664 cannot be mapped to a host ID

[luke-hill]

@olleolleolle In the last 1 year, only 1 build has passed out of 30+ for that specific job.

See: https://circleci.com/gh/cucumber/cucumber?page=0

I'm not sure why it's failing. But the other 2 pass, and I'm inclined to say given the complexity of the PR we should merge this. As it'll standardise pretty much everything for cucumber-messages (Aside from JRuby sadly)

[olleolleolle]

This change simplifies the google-protobuf story, and takes us closer to a solution for everyone.

[aslakhellesoy]

@luke-hill I'm all for upgrading to 3.8, but before we do, could you point me towards the problems we're trying to solve? What exactly are the niggling issues? Can you link to Travis builds that are failing?

[luke-hill]

A fair few of the 2.2 and 2.3 builds were failing. I can't link to specific travis ones. But often it spoke of not being able to bundle the gem / install the gem.

If that's a blocker for merging it I'm happy to close the PR. I haven't seen the issue as much so perhaps it's not as big an issue. I know going forwards they're also not really supporting JRuby; so not sure what we want to do there.

[aslakhellesoy]

What's preventing you from linking to the failed builds @luke-hill ?

[luke-hill]

Sorry, bad english. I mean I don't know where they are. I can't remember exactly where / when they occurred. I vaguely remember they mainly affected 2.2 and 2.3 Ruby builds. 2.4 / 2.5 were fine I think.

I can't remember exactly, so if you want to close this PR you can do. I just figured it would be good to standardise this up. Because a lot of the logic in 3.8 makes the gem a bit more stable, and I think it will make JRuby play a bit nicer too (Although I've no idea if it works on JRuby or not)

[luke-hill]

Are we wanting to merge this in??

[luke-hill]

I've rebased this and got it RtM. Once CI Clears we can crack on with simplifying this area.

On an aside, the protobuf team seem to be using decent supported versions now. And will likely only support JRuby 9.2, the question is just whether they'll tidy things up in the latest version of the gem