Working with Go modules whose major version is 2 or greater is different than working version 0 or 1 and is different than doing so with the tools that came before it like dep and glide. There are changes that need to be made to both the module and the way it's consumed. Having had to work through this with semver, here are some practical things I've learned along the way.
I'm happy to share that a new major release of github.com/Masterminds/semver, a semantic version package for Go, is here. This is version 3.0.0. This release was the result of following up on feedback, requests, and watching how semver was used in many real world situations. The v1 series is still in wide use and will be supported for some time. The work for that major version now happens on the release-1 branch.
Let's take a look at what's new in v3.
Go 1.13 was just released and by default is using a Google operated proxy to fetch module dependencies.
With Go modules came the inclusion of the ability to use a proxy when fetching dependencies in the form of modules. jFrog quickly launched GoCenter to provide a high performance cache. Typically, pulling modules from GoCenter was much faster than getting them from someplace like GitHub. GoCenter was optimized for performance for this use case.
Have you ever needed to pick a log package for a Go project? Should you use logrus, glog/klog, the package in the standard library, or something else? The packages have different APIs making changes later a fair amount of work.
This is all made more complex when packages that aren't applications could or should leverage logging. These packages are essentially libraries. Sometimes they do a lot. I find need to be especially true when packages could benefit from debug level logging. As someone pulling packages in that depend on different logging packages it can be a bit of an inelegant mess. Next thing you know, applications have multiple dependencies on packages that do the same thing. Like Kubernetes which depends on 5 logging packages.
Logging is just one example of this problem. There are many others. Most recently I was looking at metrics.
We can do better.
Before Go Modules and Dep there were numerous dependency managers including Glide. Glide had a lot of users and a growing following. But, when a committee of gophers decided to go in the direction that lead to Dep I was happy to have a single tool. Then when Go Modules came along I expected the single tool to continue as alternatives would be almost impossible.
By this time I expected people to be migrating from Dep to Go Modules. What I didn't expect was the number of people still using Glide.