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