On Wed, Feb 21, 2018 at 3:55 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> On Wed, Feb 21, 2018 at 11:55 PM David Anderson <d...@natulte.net> wrote: > >> Reading the latest post, https://research.swtch.com/vgo-mvs , a >> question... >> >> It feels to me like there's a missing 5th operation, in additions to the >> one you proposed: "upgrade all my *direct* dependencies to their latest >> version, but keep using minimal versions below that." I don't believe there >> is an analog to this operation in the worlds of `go get` or `dep`, but I >> think it might be an interesting middle-ground. I as the apex module >> developer want to say "I'd like to use the latest versions of the things >> I'm programming against, but I don't care about *their* dependencies – >> please defer to the library authors's opinions for those." >> >> First of all, am I reading correctly that this is not currently one of >> the options you described? If so, do you think this additional option has >> merit, compared to "upgrade the entire transitive closure to the absolute >> newest things" ? >> > > I think this operation is algorithmically trivial: Just bump the versions > in A's list to the newest ones available of each direct dependency. I > understand Russ' Article to justify that these operations can be > implemented efficient and that thus a trivial operation isn't interesting > to mention. > Agreed, from the algorithmic perspective it simplifies down to the existing operation add/remove operations, so the algorithms and properties are unchanged. What I'm arguing for (or at least, asking about), is whether `vgo get -u` should only set direct dependencies to the latest version, or the entire transitive closure. It's purely a UI/UX question, not an algorithms one. Currently, per the vgo tour, the entire transitive closure gets updated, which, per the article's definition, results in a low-fidelity build... If you assume that the intent of `vgo get -u` was "the libraries I'm calling have new features/fixes, please use them," and not "I want to use the latest possible code the universe can offer me, throughout the stack." I believe both operations have their place, and I could be convinced either way on which should be the default for "update my stuff." I'm wondering if I'm alone in thinking that "upgrade only direct dependencies, minimal versions elsewhere" is desirable as a "suggested" commandline action. - Dave > > If the "import compatibility rule" is true, there shouldn't be a downside > to do a full, transitive closure upgrade either and if this is the > standard/most common/only way to do upgrades, that would at least build > *some* force into the system, to progress through upgrades regularly. > > > -- 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.
