On Tue, 20 Feb 2018 13:02:47 -0800 David Anderson <d...@natulte.net> wrote: > > As a counterpoint to this: with vgo, I plan to make all my binary modules > specify that they want the latest versions of everything, and update that > pinning every couple of weeks/months. If I encounter bugs, I'll report > them, and move the pinning back a little, safe in the knowledge that my > dependencies will tell me if I've moved it too far back. > > I also believe the tooling around vgo should encourage/make default this > behavior for binary modules (and maybe for library modules as well, though > that's less clear to me). The default behavior when writing Go programs > *should* be to use the latest of everything, unless you have a specific > reason to hold back. Among other things, that ensures you are patched > against CVEs and whatnot.
The right choice here is not clear (at least to me). You do want the latest security patches and you will want bug fixes but you don't necessarily want the latest functional changes as APIs may not have settled down or there may be more bugs to be shaken out. Usually more stable versions are tagged and "released" but you may still choose to go with not the latest released version but one or more earlier releases. Then there are issues such as needing to run s/w on older versions of OS (not everyone updates to the latest versions -- in large organizations the delay can be very long) and often leading edge s/w will drop support for older OS versions so ideally your s/w should work on last 2-4 versions of an OS. -- 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.
