module support

[carnott-snap]

I did not see any issues or PRs for module support, so I made one

Go has released modules and while this repo does correctly tag releases, there is no go.mod file causing requires to look like github.com/gofrs/uuid v3.2.0+incompatible.

This change is backwards compatible, and should cause no breakage for existing customers.

After merge, a new tag should be pushed: v3.2.1.

[codecov-io]

Codecov Report

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

@@           Coverage Diff           @@
##           master      #74   +/-   ##
=======================================
  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 6b08a5c...c9363da. Read the comment docs.

[theckman]

@carnott-snap Thank you for your contribution, but we won't be accepting this for now. We have chosen not to adopt modules at this time, with one of the reasons being that modules being introduced would require a major version bump (4.0.0) and subsequently cause issues with consumers who have chosen to continue using dep or glide.

Please see the following for more info behind why we made this choice:

#61
#67

[theckman]

To clarify: we will look at Modules once they are no longer experimental / safe for use.

[theckman]

@carnott-snap I guess to clarify even further: we had adopted Modules, and chose to remove it after there were problems with the community consuming our package.

[theckman]

Ah, forgot we added a tl;dr to the README: https://github.com/gofrs/uuid/tree/6b08a5c5172ba18946672b49749cde22873dd7c2#go-111-modules

[thepudds]

@carnott-snap as @theckman mentioned, if you have existing packages that have already been tagged v2.0.0 or higher before adopting modules, then the recommended best practice is to increment the major version when first adopting modules. There is a bit more on the "why" here:

https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

If you are interested in more, Mark Bates recently put out a nicely done video that describes how to adopt modules from the perspective of a package maintainer. He runs through several options and examples. One of the examples he uses is how things are more confusing if the above best practice above is not followed, and how things are easier to understand if instead that best practice is followed.
I don't know Mark Bates myself, but the video is here, and I recommend it if you are a package maintainer considering modules:

https://www.gopherguides.com/videos/go-modules-package-maintainers