Manifest mode - misleading listing of available versions for a dependency

[Crzyrndm]

In manifest mode, entering an invalid version spec results in printing a list of potentially valid versions. This is mostly great, however it is misleading. While all the listed versions are indeed valid version specifications, it may be only some of them are usable because the current baseline sets a version floor.

This behaviour is non-obvious to those unused to how vcpkg works and this is not helped by the fact that getting a list of resolved versions in a short and readable manner is surprisingly difficult

• Deleting the build folder and regenerating the cmake project is my preferred way and even then there's a ton of info to parse through (ring-span-lite:x64-windows@0.7.0 -- ...\vcpkg\buildtrees\versioning_\versions\ring-span-lite\62eb02fed10bee7fd6da67269e091e41c0c7fae1 - this is verbose to the extreme)
• vcpkg/vcpkg install --dry-run gets the same info, but again is verbose in the extreme (and gets a lot harder to remember with triplets and other args involved for e.g. cross compiling)

There are several issues at play here but I will focus on the misleading "available versions" text.

• At a minimum, can the baseline version be indicated somehow. e.g.

  error: no version database entry for ring-span-lite at 0.7.1.
  Available versions:
  0.7.0
  -0.6.0#1
  +0.6.0#1 <-- baseline minimum version
  0.6.0
  0.3.0#1
  0.3.0

• Marking all inaccessible versions somehow would be better
  • versioning that doesn't have any order is still somwhat misleading if only the baseline is marked
  • It's still not totally clear that versions < baseline are inaccessble on the ordered specs
• Consider adding an obvious note/warning when the version spec from vcpkg.json is upgraded by baseline / dependency. The current behaviour does not highlight to a user that seemingly unrelated changes my cause a lib version to change

[dg0yt]

While all the listed versions are indeed valid version specifications, it may be only some of them are usable because the current baseline sets a version floor.

AFAICT the baseline sets a version default, not a version floor. And the git HEAD sets a ceiling.

Choosing lower versions (via overrides) is more likely to choose unbuildable configurations. So marking the baseline can add value indeed. (And for all other version, printing the ref as a baseline alternative could be useful, too. But this would add much more output.)

[Crzyrndm]

While all the listed versions are indeed valid version specifications, it may be only some of them are usable because the current baseline sets a version floor.

AFAICT the baseline sets a version default, not a version floor. And the git HEAD sets a ceiling.

For a git registry at least (not submodule. I have private deps), my testing shows it to be a version floor, not just the default. Lower versions are only accessible through overrides

Either way, the behaviour is significantly non-obvious and some additional details are needed in a few places

[dg0yt]

Lower versions are only accessible through overrides

Sure. AFAICT version>= and overrides is what is offered in addition to the baseline.

Your initial post doesn't make it explicit because it doesn't show an extract from the manifest. Let me try to elaborate:

• You manifest uses "version>=": "0.7.1".

• Vcpkg complains that the version doesn't exist, and suggests alternatives.

• Some of the suggestions are not suitable for version>= due to active baseline. This restriction is "not obvious".