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

Add 1.22 mux support #570

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

dgduncan
Copy link

@dgduncan dgduncan commented Jul 26, 2024

This PR seems large; however, it fundamentally accomplishes 3 things.

  1. Upgrade GO version to 1.22
  2. Add compatibility for the new 1.22 mux functionality to retrieve provider values
  3. Removes all instances of ioutil with their non-deprecated io and os alternatives.

This this change and without any other modifications, this change breaks backward compatibility for GO <1.22. This can be fixed however by creating a new gothic.go | gothic_test.go with //go:build go1.22 with these breaking changes. I am happy to make these compatibility changes but would love to get other's opinions first.

@dgduncan dgduncan marked this pull request as draft July 26, 2024 12:13
@dgduncan dgduncan marked this pull request as ready for review July 26, 2024 12:16
Copy link
Collaborator

@techknowlogick techknowlogick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR!

One tiny nitpick: I'm hesitant to bring the minimum up to 1.22 as goth is used by many downstreams, some of which still have much lower minimums. Would you be able to add in a polyfill for the new capabilities if the library is being used with a version of go that doesn't support them?

Meta: I do recognize the weirdness of asking for this as it means folks using older versions of go would be upgrading goth but not go (I've long given up on trying to understand some upgrade policies, and if an accommodation can be made without impact to security or significantly increasing maintenance burden, then I do try to at least investigate)

@dgduncan
Copy link
Author

dgduncan commented Aug 3, 2024

@techknowlogick I am open to ideas. I extracted out the getProvider functionality into two new files; each tagged with a version check. I would love to see if this now passes the tests of the pipeline. If you have a better idea for how to implement such backwards compatibility I would love to know. I am not super familiar with this type of backwards compatability.

@dgduncan
Copy link
Author

dgduncan commented Aug 4, 2024

Ok it looks like my change passes the tests; however, I still want to do some individual testing. Also I do not know how I feel about the provider_legacy naming. @techknowlogick @markbates do you have an opinion?

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

Successfully merging this pull request may close these issues.

2 participants