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

Remove support for Go 1.11 modules #67

Merged
merged 2 commits into from
Jan 11, 2019

Conversation

dylan-bourque
Copy link
Member

Remove go.mod and add notes to README.md indicating opt-out for Go 1.11 Modules.

This PR probably also resolves #61, but not to the satisfaction of the original submitter. After much discussion, it's actually not supported to have a single import path for both module-aware and module-unaware consumers for v2+ packages.

@codecov-io
Copy link

codecov-io commented Jan 7, 2019

Codecov Report

Merging #67 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #67   +/-   ##
=======================================
  Coverage   98.92%   98.92%           
=======================================
  Files           4        4           
  Lines         279      279           
=======================================
  Hits          276      276           
  Misses          2        2           
  Partials        1        1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9f278e1...2d35c48. Read the comment docs.

Copy link
Member

@theckman theckman left a comment

Choose a reason for hiding this comment

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

@dylan-bourque thank you for taking the time to do this. While doing some noodling on this today, while my relatives all spoke a language I don't understand around me, I realized that this is probably going to fuck over any library maintainer who has migrated to gofrs/uuid. (👋 @markbates) Anyone who tries to use their library will fail to resolve the /v3 import, and their only recourse will be to nag upstream or fork/patch.

I don't think it's a step we can take. I'm thinking we need something more akin to #66 in terms of code, with the README copy from this PR. However, one addition to that PR would be to add a blurb to the top of the README deprecating the /v3 import by a specific date. We should not include a go.mod file in /v3 either.

How about $now + 100 days? Gives everyone three months to migrate away from it, and a few days for us to merge without it going under 90 days. 😉

Edit: retained for transparency; we did not need to take this path and could just remove modules support. Everything should mostly be okay as a result, with new consumers not using the SIV (/v3) import.

@theckman
Copy link
Member

theckman commented Jan 8, 2019

cc: @itsjamie

@itsjamie
Copy link
Contributor

itsjamie commented Jan 9, 2019

That works for me. I'll reopen #66. @dylan-bourque it's off a branch in this repo, can you commit the README blurb there?

@dylan-bourque
Copy link
Member Author

@itsjamie I thought the decision (in the #gofrs Slack channel) was to go with this PR (not creating the /v3 folder). I'm confused.

@itsjamie
Copy link
Contributor

@dylan-bourque ignore me. I was confused :) 👍

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.

Unstable Import Paths
6 participants