VERS cannot model version trees with branches or when sorting two version is undefined

[pombredanne]

We have some problem when we cannot sort two versions, since the canonical order is with sorted versions:

• Semver build metadata https://semver.org/#spec-item-10 there is no precedence between two "same" versions with different build metadata
• Erlang versions (and others) have branches and we cannot model branches in a single VERS today -https://github.com/erlang/otp/blob/maint/system/doc/system_principles/versions.md#version-scheme
• CVS encodes branches in version numbers - https://en.wikipedia.org/wiki/Concurrent_Versions_System
• OSes:
  • Cisco IOS uses a branched versioning system where the first segments are a branch, somewhat similar to Erlang, but using also trailing letters.
  • Using Debian "revision", Ubuntu pads an upstream version with -ubuntu to treat upstream version as a base, and the revision as a branch. This can avoid updating ubuntu with debian.
  • RPM's structured release string "el" plays the same role, for instance 1.2.3-4.el8 where el8 is the RHEL 8 branch of the version 1.2.3, build 4, vs. 1.2.3-5.fc43 which is in the Fedora 43 branch: this can avoid updating rhel with fedora.
  • Windows and AppleOS both use some kind of branching system too with either a build segment of a trailing letter (Apple)
• Common packages like OpenSSL have a line of version in the 1.x branch and another line in the 3.x branch that are quite different, almost different tools.

[pombredanne]

We will need to devise a proper way to sort undefined orders, or to encode trees in VERS.

[ppkarwasz]

Should we say that we require version numbers to be a totally ordered set? 😜

[maennchen]

@ppkarwasz That's what #143 essentially requires. The idea is to possibly remove that requirement for later versions.

[keshav-space]

Related issue: aboutcode-org/univers#119

[johnmhoran]

Thank you, @keshav-space , I've been wondering why we use mere pipes with no meaning beyond "I'm a separator". ;-)