I can’t seem to converge on a decent package/version management scheme. I asked Dave Cheney, and he recommended that I email this list.
I’ve written a Go project. I started with a directory tree like this: $GOPATH/src/project/objects/agent_v1/agent_v1.go (import “project/objects/agent_v1”) $GOPATH/src/project/objects/customer_v1/customer_v1.go (import “project/objects/customer_v1”) Etc. I know that I needed to be able to support different versions of my objects, so that is the directory structure I started using. ( I am a newbie at using VCS tools. Currently using GitHub, to clone a repository, add, commit, and push. No version numbers, releases, branches, forks, tags, etc., because I am a newbie at Git.) Then, I started using one of the Go lint programs, and it complained about the underscores in my package names. That made me reconsider how I was versioning my packages. Also, how would I mature in my usage of GitHub as a VCS (with releases, branches, forks, tags, etc.). It also prompted me to ask “What is the Go way to deal with this?” There must be a recommended way. Little did I know, it seems like there are lots of options, with no clear winner. Alternatives: 1) Change “agent_v1” to “agent-v1”. Suggested by: *http://zduck.com/2014/go-and-package-versioning/* <http://zduck.com/2014/go-and-package-versioning/> Opposed by: *https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project* <https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project> 2) Change “agent_v1” to “agentV1”. Ugly. The only thing that distinguishes the version number is the uppercase “V”. Opposed: *https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project* <https://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project> 3) Using *http://labix.org/gopkg.in* <http://labix.org/gopkg.in>. I don’t like this because it forces the “go-pkg/pkg” naming scheme. 4) “dep”: looks like it will be the official tool, but not yet ready for prime time. 5) gb: Replaces some Go tooling. Will it eventually be replaced by “dep”? 6) Vendoring. I don’t understand it well enough to tell if it would help with versioning. 7) *https://github.com/golang/go/wiki/PackageManagementTools* <https://github.com/golang/go/wiki/PackageManagementTools> I’ve looked at most of these, and I don’t see a clear winner. Also, it is unclear if I adopt any one of them, how much work it will be to move to “dep” (once it becomes available). I’d love to adopt SemVer 2.0.0, as Dave Cheney suggests (in *https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases* <https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases>), but I can’t see how that will work with the Go tooling. What I’m looking for: A solution that will: a) make builds reproducible. b) use SemVer 2.0.0 versioning. c) use the full power of GitHub (releases, branches, forks, tags, etc.) d) use GitHub tags as a versioning mechanism, instead of version names embedded in directory paths. e) use the standard Go tooling as much as possible. Only use other tooling where the standard Go tooling won’t work for package/version management. f) minimize work needed to adopt “dep”, or whatever package/version management the Go community eventually converges on and adopts. It seems like this is an area under flux. I can’t see it converging. (Maybe that is my fault; I’m a newbie). Dave's advice: Use gb and semver, *https://github.com/golang/go/issues/12302* <https://github.com/golang/go/issues/12302>. If gb isn't your thin, I recommend github.com/dpw/vendetta. Anyone else have a recommendation? Jeff Kayser Jibe Consulting | Managing Principal Consultant 5000 Meadows Rd. Suite 300 Lake Oswego, OR 97035 O: 503-517-3266 | C: 503.901.5021 *jeff.kay...@jibeconsulting.com* <jeff.kay...@jibeconsulting.com> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
