On Tue, Feb 20, 2018 at 12:46 PM, Bakul Shah <ba...@bitblocks.com> wrote:
> On Tue, 20 Feb 2018 11:55:00 -0800 "Devon H. O'Dell" < > devon.od...@gmail.com> wrote: > Devon H. O'Dell writes: > > 2018-02-20 11:39 GMT-08:00 Russ Cox <r...@golang.org>: > > > On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell < > devon.od...@gmail.com> > > > wrote: > > >> > > >> With regards to minimum version selection, if I depend on some feature > > >> present, this comes with two implicit dependencies: correctness and > > >> safety. My knee-jerk reaction here is that the time folks spend > > >> "telling the package manager, 'no, use at least Y,'" will largely be > > >> in response to these sorts of issues. Maybe this is seen as "working > > >> as intended;" my feeling is that this will become tiresome for > > >> projects with large dependency chains. Might it be worthwhile (and > > >> automatically possible) to pick the "maximally correct" minimum > > >> version? > > > > > > I am not sure what you mean by "maximally correct". > > > I think that's approximately what all the other package managers try > to do. > > > It makes things very complex (literally: > research.swtch.com/version-sat). > > > > Thanks. I was thinking in terms of e.g. a "correctness counter" that > > could be published. If I depend on e.g. foo.Bar, I automatically want > > the least buggy version of foo.Bar. If foo.Bar appears in version 1, > > the amount of work required to find the least buggy version is > > directly proportional to the number of releases in which foo.Bar > > appears, and is annotated as having some correctness fix. I don't > > think this would necessarily be as complex as you point out in the > > referenced post: this is a property of an individual package. Of > > course, you want the same property for each package's dependencies, > > but that can be decided without conflict using the same methodology > > for each package. That is, I don't think there's a case for package X > > with a dependency on package Y where the minimum version can't be > > decided in linear time. > > I had a somewhat similar reaction as Devon. > > Reproducible builds are indeed very desirable but, as Devon > hints at, it is also the case that differences between > versions grow over time and implicit assumptions may break. > For example, updating from v1.1 to v1.5 and then v1.10 may be > easier than updating from v1.1 directly to v1.10. That is, > updating version depdendencies from time to time may be > considered part of regular maintenance. > > *Once* you release a package you want its dependencies > explicitly stated for reproducible builds but when creating > the next release of the same package, you may want to update > to later versions of imported packages due to the above > considerations. > > May be one can write a tool around or similar to "vgo test" to > test and update not to the latest but some earlier version. > For example, if pkg A currently imports C v1.x and B imports C > v1.y, through iterative testing one may find C v1.z that works > for both and update go.mod files for both A & B. > > The underlying concern is that with better tooling to manage > versioning, there will also be more versions to manage as > there is less of an incentive to try to make things work with > the latest versions of imported packages. 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. In my mind's eye, the version declarations that modules make for consumption by other modules is the tail end of the world's sliding window of "what set of stuff can build together". It should not be the default place that most Go binaries live. - Dave > I wondered if there > is a way to encourage/improve the quality/correctness aspect. > One vague idea is to consider specifying tests (in go.mod) to > be run prior to an update. Sort of like asserts in code. > > Apart from this concern vgo seems like a huge improvement. > Well done! > > -- > 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. > -- 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.
