rubygems is not semver

[oliverchang]

e.g. rails: https://rubygems.org/gems/rails/versions/6.1.3.2

I see you try to coerce this into a semver:

https://github.com/nexB/univers/blob/63bd5aec16ec95b5b811ede638ac225f3ab1f6c6/src/univers/versions.py#L107

but this isn't correct, because it gets coerced to "6.1.3+2". and the "+2" part is not considered for ordering purposes per https://semver.org/spec/v2.0.0.html#spec-item-11

>>> SemverVersion('6.1.3.2') < SemverVersion('6.1.3.3')
False

See also https://snyk.io/blog/differences-in-version-handling-gems-and-npm/ for more issues with trying to handle ruby versions as semver.

Other ecosystems may have similar problems. E.g. composer recommends following semver, but it also doesn't enforce it: https://getcomposer.org/doc/articles/versions.md

[pombredanne]

@oliverchang Thank you ++

[pombredanne]

We may end up having many more version schemes and comparison all re-implemented, but that's OK, that's what is needed anyway. And when we attack the dependency resolution problem for aboutcode-org/dependency-inspector#1 we will at least have solved a key part. For dependencies, I am pretty sure that resolution is devilishly different for each package type and ecosystem, or worse because there are eventually multiple resolution algorithm and tools that can exists for any given package type in most cases (except may be for the most recent projects in the youngest ecosystems like Go or Rust)

[pombredanne]

The PR #14 adds support for Rubygems version comparison using a proper port of Ruygems version.rb and requirement.rb and a full implementation of version range spec