Version schemes semver and relaxed are uncomparable

[horenmar]

Describe the bug

It is my understanding that version schemes semver and relaxed are comparable, in other words I can use version>= constraints for packages using these schemes.

However, when I try to do it with e.g. fmt, I get this error message:

Error: Version conflict on fmt:x64-windows: baseline required 8.1.0 but vcpkg could not compare it to 8.0.1

The two versions used incomparable schemes:
    "8.0.1" was of scheme semver
    "8.1.0" was of scheme relaxed

This can be resolved by adding an explicit override to the preferred version, for example:

    "overrides": [
        { "name": "fmt", "version": "8.0.1" }
    ]

Environment

• OS: Windows
• Compiler: N/A
• vcpkg version: Vcpkg package management program version 2021-12-09-724cea8b33cbf06c645f5095fa29773697da9761

(that's the same version as what I currently get after doing git pull and bootstrap-vcpkg.bat -disabledMetrics)

To Reproduce

Try building manifest mode for this project:

vcpkg.json

{
  "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg/master/scripts/vcpkg.schema.json",
  "name": "version-repro",
  "version": "0.0.0",
  "dependencies": [
    {
      "name": "fmt",
      "version>=": "8.0.1"
    }
  ]
}

vcpkg-configuration.json

{
  "default-registry": {
    "kind": "git",
    "repository": "https://github.com/Microsoft/vcpkg",
    "baseline": "03ca9b59af1506a86840e3a3a01a092f3333a29b"
  }
}

and e.g. empty CML.txt:

cmake_minimum_required(VERSION 3.19)

project(version-repro LANGUAGES CXX VERSION 0.0.1)

Steps to reproduce the behavior:

Expected behavior
I expect these two version to be comparable and to get 8.0.1 of fmt package

[BillyONeal]

I wanted to do this when we added the semver extra bits to the relaxed version scheme (allow more cross-scheme comparisons) but it's complicated because the different schemes can parse as each other but have different comparison rules. For example, 2021-01-01 can be a relaxed version (with "2021" as the only number and "-01-01" as the build tag suffix) or a date version and we really needed the user to tell us which.

Perhaps allowing cross between "semver" and "relaxed" alone should work here.

[horenmar]

Well, most of my internal ports are still uncomparable because we do date-versioning with YYYY.MM.DD, so, not really happy, but this does make my life easier. :-P

versions that were different but not obviously orderable e.g. 2021.01.01 and 2021.01.1.

I claim that outside of the domain of version-string, these should be parsed into the same dotted version.

[BillyONeal]

That would break one of the design rules that any input has a unique parse into a total order. In your case I would strongly recommend just using version-date.

[dg0yt]

"2021.01.01 and 2021.01.1" would have have the same unique parse ("2021.1.1"), as do "21.0.0 and 21". It is a one-way funtion. In fact projects do choose the 2021.01.01 syntax exactly because it is a normal version number. Leading zeros simpy have no relevance in numbers and in dates.

The actual problem is "21.02" etc. which is not a valid version-date. "21.2" and "21.02.01" are different spellings which makes external comparison more difficult, even for equality

[BillyONeal]

"2021.01.01 and 2021.01.1" would have have the same unique parse

It doesn't matter that they have a unique parse. The invariant we wanted to maintain because we use file hashes all over the place is that the text is unique, not that it can parse into the same thing.

[dg0yt]

This is not just a theoretical problem. There is poppler 21.01.0, and most repositiories do fine with such versions:
https://repology.org/project/poppler/versions

[horenmar]

For posterity, the issue with versions with leading 0s is that the version database search is done with exact string match, due to version-strings.