Indeed, that's where we are coming short. The Go ecosystem does not own its package releasing process. (with a release identification scheme that may different from semver since we do not need to worry about major versions for reasons of different release semantics)
A `go release` command that would prepare a package for release could be the addition required. It will most likely require to have a centralization of these package releases. Declined under a solution that can be internal for companies that need a tighter control over their dependencies OR fully web facing for gophers in the large). I say package releases, but the repository can be anywhere people want, I don't think Google has to deal with the hosting of repos. On Tuesday, August 2, 2016 at 10:20:59 AM UTC+2, Dave Cheney wrote: > > That's somewhat the intent in enabling the timestamping of packages >> especially wrt. library-vendored package. >> Flattening dependencies will still be needed but it would be simply a >> matter of switching a package to the latest package release that a package >> may have vendored. >> >> > To do this you need to have some _machine consumable_ notion of what is > the "latest release" of a package. This currently doesn't exist for Go > projects. > -- 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.
