SemVer range represents range-set

[timreichen]

Is your feature request related to a problem? Please describe.

Ref: #3957 (comment)

The semver mod was taken over from node-semver. range actually represents a range-set.
I opened an issue on node-semver to find out the reason why.

We should differentiate between range and range-set to avoid confusion.

Describe the solution you'd like

rename range files and functions to range_set aka. RangeSet and deprecate all old functions.
In a next step, reintroduce old range functions with the implementation of a real range.

Describe alternatives you've considered

[iuioiua]

Another suggested name would be Range. If we proceed with the suggested change, we should also promote the ranges property of SemVerRange as the value itself. It being nested looks unnecessary. I.e. functions should use ranges instead of the current range.ranges.

Another requirement we should question is whether the ranges property needs to be a nested array. In other words, is the outer array being used for OR comparisons and inner arrays being used for AND comparisons actually necessary? I expect that it is necessary, but I think it should be questioned. If it were found to not be necessary, we could just have a ranges type that is a flat array with a depth of 1 that could make things much simpler.

I hope my thoughts make sense. Happy to try clarify if they don't.

[timreichen]

Another suggested name would be Range. If we proceed with the suggested change, we should also promote the ranges property of SemVerRange as the value itself. It being nested looks unnecessary. I.e. functions should use ranges instead of the current range.ranges.

What do you mean exactly with "promoting the ranges property"?

Another requirement we should question is whether the ranges property needs to be a nested array. In other words, is the outer array being used for OR comparisons and inner arrays being used for AND comparisons actually necessary? I expect that it is necessary, but I think it should be questioned. If it were found to not be necessary, we could just have a ranges type that is a flat array with a depth of 1 that could make things much simpler.

imo a Range should be defined as the following:

type Range = [Comparator, Comparator]

which actually represents a range between two versions, like a segment on a line:
Example: >=1.2.3 [AND] <2.0.0.

A RangeSet represents multiple segments on the line and therefore needs to be an array of ranges:

type RangeSet = Range[] // [Comparator, Comparator][]

Example: >=1.2.3 [AND] <2.0.0 [OR] >=3.0.0 [AND] <4.0.0

It therefore necessarily needs to be a nested array and cannot be flattened.
But we can definitely reduce the nested array complexity because after we reimplement Range functions, we can deprecate most of the RangeSet functions again.

[kt3k]

The semver mod was taken over from node-semver. range actually represents a range-set.

That BNF file only looks like a non official reference for implementers of node-semver. That doesn't give reason for introducing RangeSet concept in std/semver. Having both SemVerRange and RangeSet sounds just confusing and too strict to me.

[timreichen]

Closing this since Comparator is deprecated now.