3 ms·
> Instead of trying to get the latest version it's going to try to get the oldest. No, minimal refers to the number of dependency changes between upgrades, not
by deckar01 9y ago
> Instead of trying to get the latest version it's going to try to get the oldest.
No, minimal refers to the number of dependency changes between upgrades, not the version numbers of the dependencies. Dependency conflicts initially resolve to the higher of the two versions.
https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs section "
Algorithm 1: Construct Build List"
In the example, a dependency is upgraded and no longer needs one of the shared transient dependencies. Instead of downgrading it to the version declared by the unchanged dependency, it keeps the higher version that you were already using. When upgrading, transient dependencies are never downgraded, only added (or removed).
https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs section "
Algorithm 3. Upgrade One Module"
- mfer 9y agoLet's say you have the following picture... App --> Dependency A --> Dependency C (at version 1.2.3) --> Dependency B --> Dependency C (at version 1.3.4) The latest release of Dependency C is 1.4.5. Which version would be used after running `vgo get -u`? As you note it would use the newer version of those specified (version 1.3.4). The newer releases after those explicitly specified are not used.
- sseth 9y agoI believe (having tried the tour) that you will get v1.4.5 at the App level, if you do vgo get -u. If you just do plain vgo get, you will get 1.3.4, because of the minimum version approach.