Hacker News Reader

Comment by mfer | Hacker News Reader

Submodules and even subtrees can be useful ways to link repos. But, I'm wary of commit ids as versions. From a commit id you can't tell if the version you can is after the version that fixed a security issues. You can't tell what version of the interface to the package you're using. The meaning we are able to pull from and even compare with version number is missing. And, submodules are pinned to commit ids.

View on HN

I see where you're coming from and agree that commit IDs aren't very friendly, but from a technical perspective it solves the same problem of having dependencies on specific versions of software.

Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.

A few reasons we don't just use submodules

- The Go community supports Git, Svn, Bzr, and Hg. We keep that up. According to the Eclipse community survey, 2014 was the year Git usage passed Svn usage. Svn usage is still quite high. - A lot of developers struggle with and even have strong negative opinions of submodules. So much so that we now have subtrees. I've find a lot of developers would prefer not to use them. - The way Glide works is in line with the package managers from the other major/popular languages. This way it's familiar to many people coming to Go by solving the same problem in the same way they're already used to.

Typical Git usage is to create a tag for every release, giving it a nicer name than a raw SHA1 sum. You can check out a submodule to such a tag too.

Reply on news.ycombinator.com