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. 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.
