I'm not faulting anyone. Or any of the projects. I'm pointing out the fact that standardization of package version mangement from the package maintainer's side

I'm not faulting anyone. Or any of the projects. I'm pointing out the fact that standardization of package version mangement from the package maintainer's side is something the Go community hasn't agreed on. All your replies describe workarounds. Use a git hash. Use the master branch. I did those. The point is that even if we haven't figured out package management within the software industry, we do have more mature practices than this. Do I expect the author to tag a release every time they push to master? Kind of actually. It depends on what's going into master. If it's typo fixes. Sure that can wait. If it's major bug fixes, that probably should be a release. If it's brand new features added, then yes! It has to be a release! Right now, people are treating each commit to master as a new release. I'm not angry or railing against anything. I'm an outsider who went through a lot of strange things in my first project in Go. I think this line from nlopes/slack README highlights the general package management methods: "v0.2.0 - Feb 10, 2018 Release adds a bunch of functionality and improvements, mainly to give people a recent version to vendor against." All I'm saying is that it'll be great if the community does figure this out and settles with a single agreed on practice. --- One last example: stretchr/testify is a library I considered using for testing. Their README encourages people to depend on the master branch. And even this PR acknowledges the issues that has caused: https://github.com/stretchr/testify/pull/274 https://github.com/stretchr/testify/pull/274 . I agree that there are workable workarounds. But that's exactly what they are. Workarounds.