Conan: [feature] Use numerical version comparison in range resolver as long as version string is in the format a.b.c(.d.e)

[jasal82]

We tried to use four-digit version numbers and resolve them with version range expressions. The handling of these (non-semver-compliant) version strings seems to be inconsistent in Conan. With Conan on Linux we observed that a version 3.8.0.1 is considered newer than a 3.8.0.0 when resolving the range [*]. Trying the same on Windows resolves always to 3.8.0.0. There were also reports that for some users it would yield unexpected results on Linux as well, but I haven't confirmed that yet.

I think it would be beneficial if someone could look into this and rework the range resolver so that strictly numerical versions in the form a.b.c(.d.e...) still behave according to semver as far as the first three digits are concerned. Any extra digits (.d.e...) should be semantically equivalent to the patch version and compared numerically up to the first - or +. What do you think?

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @jasal82

We tried to use four-digit version numbers and resolve them with version range expressions. The handling of these (non-semver-compliant) version strings seems to be inconsistent in Conan. With Conan on Linux we observed that a version 3.8.0.1 is considered newer than a 3.8.0.0

Yes, we are aware of that issue. And I wouldn't mind to have that support.

But the main problem with this is that the range-resolver is based on the python node-semver (https://pypi.org/project/node-semver/) library, which is out of our control. Such library just ignores other digits after the "patch" version, so the results are unexpected or unsorted.

Even if we could fork it and maintain our own fork, it doesn't seem an easy task, and our backlog is already huge. Have you tried suggesting this feature to that project (https://github.com/podhmo/python-semver)?

[jasal82]

I see. I will suggest the feature in the python-semver project then. Thanks for the clarification.

[peterwaller-arm]

This has landed on node-semver 0.8.0. Here is the upstream issue where it is resolved. Very little has changed in node-semver since 0.6.1, which conan specifies as an exact dependency:

https://github.com/conan-io/conan/blob/bd5920a40d9707001b31966adb0dfa7d6af00eea/conans/requirements.txt#L9

Please can someone update the dependency to >=0.8.0? I would have sent a pull request but unfortunately I would have to seek approval to do so, so it would take a while.

[RalfBielig]

This has landed on node-semver 0.8.0. Here is the upstream issue where it is resolved. Very little has changed in node-semver since 0.6.1, which conan specifies as an exact dependency:

https://github.com/conan-io/conan/blob/bd5920a40d9707001b31966adb0dfa7d6af00eea/conans/requirements.txt#L9

Please can someone update the dependency to >=0.8.0? I would have sent a pull request but unfortunately I would have to seek approval to do so, so it would take a while.

Waiting badly for the update.
In many project we use the 4 digit version numbers.

[dribeas]

Are there plans to support overriding the versioning scheme? For example, openssl does not use semver at all, which forces us to pick an specific version of the library where in most cases we don't particularly care (and would not want to have to edit all our recipes whenever we change openssl.

[djeverett]

Any action on this? It would be really useful to have this, and it is just a one line change to requirements.txt.

[memsharded]

Are there plans to support overriding the versioning scheme? For example, openssl does not use semver at all, which forces us to pick an specific version of the library where in most cases we don't particularly care (and would not want to have to edit all our recipes whenever we change openssl.

That is a different story, probably deserves another issue to suggest. Do you mean, you want to provide your own python logic to define what falls in a version range? This is basically what node-semver lib does, and it is not a straightforward thing, so this might be even a bigger pain to maintain for the users?

[memsharded]

Any action on this? It would be really useful to have this, and it is just a one line change to requirements.txt.

Assigned to next 1.26. But we can't promise, this being pinned to a specific versions is a very bad sign, most likely upgrading will break things.

[memsharded]

Can you please try to force upgrade the pip install node-semver==0.8.0 on your side, and check if everything works on your side, and you can use 4 digit versions with it?

[peterwaller-arm]

We're using node-semver==0.8.0 in prod, haven't encountered an issue with it. Upgrade appreciated!

[memsharded]

This would be too risky, means dropping semver specification standard, might be breaking for many people. Moving to 2.0 for consideration.