Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds gomod support as an alternate to #97, and implements #85.
In #97 , we discuss a proposal to fork the repo to stay perpetually at major version 0 so as to not force users to provide maintenance on their import paths. It's been a year since that proposal was opened and there's been no major steps to move us to a different repo or incorporate modules. In the meantime, the go ecosystem has moved on to grow the maturity of go.mod and it is increasingly making less sense for us to not comply with the standard package management for go.
Irrespective of the history this module has with go.mod (see notorious #61 and #65), the status quo has changed and consuming packages are no longer in flux with glide, dep, and gomod in a way that we need to support all at once. In this PR we take the appropriate cautious (potentially unnecessarily so) step and incorporate gomodules as a major version increment in order to bypass strange problems with import versioning.
To provide a complete proposal for merging this PR, here are some pros and cons.
Pros:
Cons:
For the first con, consumers who are unhappy with this change should strongly consider wrapping their usage of
gofrs/uuid
in a UUID module so that they only have to update one import path when they upgrade this repository.Additionally, for maintainers of this library, it is important for us to be aware of but not paralyzed by the impact of making breaking changes to the library. But we've already been cautious and disciplined about making breaking changes. We have not made one in 2 years, and even though we're experimenting with v6 ad v7 UUIDs, there's nothing indicating that we are going to need to break the API anytime soon. Still, users can mitigate the blast radius by wrapping this package if they really are concerned about the imports becoming noisy.
I'll leave this PR open for a week to collect feedback.