Maximum version information is not communicated.
Note, I'm the posts author.
> This is a slightly tangential issue to pinning. With MVS and vgo you cannot set a maximum version. When the resolver walks the tree it doesn't know when a version is too new and could break things. Even if it pins it could pin an incompatible version.
This just isn't true. The number you put in the go.mod file can't encode the max version: true. But it won't change underneath you so when you run "vgo list -m" and determine the solved version, it won't change from that.
It's not a lock and from what I gather from Russ not intended to be.
The solved version doesn't mean it's the right or even a compatible version. This issue here is no maximum version meaning it could solve for an incompatible version due to not having all the information about the complete tree.
> It's not a lock and from what I gather from Russ not intended to be.
go.mod files lock versions into place. If you disagree read the code / design documents. I find it dishonest to say something technically true "It's not a lock [file]" and yet not be true, as it together locks versions in place.
Assuming git tags don't move.
The issue it does have is one where a transitive dependency is known bad by one of your immediate dependencies, but there's no way to declare that to the resolver.
Here's a concrete case:
1. I depend on cool-framework, min 1.5.0
2. I depend on boring-library, min 1.0.0
3. cool-framework depends on boring-library, min 1.0.0
4. cool-framework receives bug reports that boring-library 1.5.0 breaks cool-framework.
5. I upgrade boring-library to min 1.5.0. Everything builds and tests okay, but I get breakage in my staging env.
There wasn't non-deterministic package install behavior, but I still ended up with breakage that could have been prevented after (4) in a system that allows library dependencies to articulate more complex version constraints than "min version". In Rubygems or Python, with or without a lockfile, cool-framework could update its dependency on boring-library to specify "min 1.0.0, less-than 1.5.0" until the breakage is fixed.
There are problems either way. I think the other benefits that MVS enables is worth choosing one of these problems over the other.
Edit: As mentioned upthread, vgo supports exclusions for the top-level module. This doesn't directly help here currently, but what if exclusions in dependencies produced a warning of a possible incompatibility instead? I think that would solve the issue of you not knowing that an upgrade could break things.
Bugs happen, and users should have some tools for that situation, but if a library is repeatedly releasing one broken version after another, you probably just shouldn't use it.
Your assumption here is that it was the boring-library version 1.5 that was broken, in reality it could be that they changed something that wasn't documented and was only an implementation detail, but was relied on by cool-framework (e.g. getting a list back sorted in one particular way in 1.4 and sorted in another way in 1.5 where the order was never part of the API contract).