I think there is a bigger concern than shipping binaries. I believe that the Go stdlib and runtime should be shipped as a shared library, and be field upgradable independent of the binaries. This is the only reasonable way to to distribute security patches in an efficient and stable manner.
This is another issue, but there is some cross-over with this discussion. > On Oct 22, 2018, at 8:53 PM, Fino <xme...@gmail.com> wrote: > > I think Binary-only packages are very important for Go's Eco, something like > maven(Java) & sbt(scala) > > - all it's dep packages should save in the same repo, together, like a > snapshot, or similar concept like docker image > - use a manifest file to list all the dep package's name and version > > it's ok that when the binary release, it was compiled with a older version of > Go; and after that, no body maintain it and cannot compile by newer version's > Go. > > if it just can run and still works good in a living OS, it should stay in a > global repo and let people can download and use it. > many system don't need update for many years after release, and impossible to > recompile all it's libraries against newer compilers. > > BR fino > > > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
