Even if golang hasn't any notion of "version" for a lib, we can use some external tool to manage dependencies versions.
For example we are using https://github.com/gpmgo/gopm .
With tags, we can be able to have the same behavior between any build machine at any time.
This package is versioned by source commit. If you need a reproducible build, reference the git tree by commit like 6f6c32d. There are no plans to add a different versioning scheme like semver or other ordered/meaningful reference to source commits.
Is there any chance to revise this decision? There are package managers for Go (godep, glide, etc) and there is one (dep) which is going to be the official one.
@sagikazarmark it's been discussed more than once since Dec 2014. Things will stay as they are in the short term. I personally think that using branches for release series and tags would be better.
Maybe once Go adopts an official package management tool, this can be revisited.
I really think this should be reopened and reconsidered soon, as Sam Boyer mentions dep
is production ready and is on the road to be implemented into the Go toolchain so it's a good time to start migrating to a version system.
Yes revision SHA1's are an acceptable workaround but semver just makes more sense, is easy to distinguish newer from older and is simply just prettier!
Hello!
Any plan to add a release tag ?
Most helpful comment
I really think this should be reopened and reconsidered soon, as Sam Boyer mentions
dep
is production ready and is on the road to be implemented into the Go toolchain so it's a good time to start migrating to a version system.Yes revision SHA1's are an acceptable workaround but semver just makes more sense, is easy to distinguish newer from older and is simply just prettier!