I think we're agreeing, with different words (but please correct me if I'm wrong!).
Yes, active maintenance is required with vgo, as demonstrated in the tour. But crucially, I do not get held back by library writers that don't update, I'm only held back by my own laziness in failing to update at the apex of the dependency tree. That's something I can automate away. It probably means I'll be a beta tester for a new combination of versions more often than not. But `vgo test` helps with that, and generally encourages the writing of useful tests, so again I think the incentives all align. And when they don't, there's the replacement mechanism to fork in place. - Dave On Tue, Feb 20, 2018 at 1:20 PM, Devon H. O'Dell <devon.od...@gmail.com> wrote: > 2018-02-20 13:02 GMT-08:00 David Anderson <d...@natulte.net>: > > [snip] > > > > 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. > > AIUI, that is the opposite of what minimum version selection does; > active maintenance is required. This is at least no worse than any > other case where you need to make a determination on whether to > consume some library or tool based on whether it is actively > maintained. And when the tools are maintained, seems like it is > probably better. > > --dho > -- 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.
