Add more Version / Range capabilities

[lizmat]

• add support for ^v1.2.3 aka all versions upto/not including v1.2.3
• add smart-matching to allow v1.1 ~~ v1.0 .. v1.2 to work

[JJ]

👍

[ugexe]

I think the ^ stuff is going to be confusing.

While raku versions aren't semver, users will often mistakeningly believe it to be the case. This is unfortunate because while it makes sense for e.g. ^1 to be anything less than 1 in raku, in semver it means $ver >= 1 && $ver < 2. I'm not sure what to do about this.

Using ^v1.0 (i.e. raku range of version) is not generally useful enough. When declaring dependencies we do not use the v, and thus one would expect to write Foo:ver<^1.0> (i.e. a raku version range), not Foo:ver<^v1.0>. For example:

$ raku -e 'say Version.new("v1.0")'
vv.1.0

In other words: Version.new(...) needs to be able to parse and understand this new mechanism similar to how it handles + and *. Users should be able to write Version.new("^1.0") (and probably v^1.0 as well).

[lizmat]

@thoughtstream ping

[Leont]

This think this is useful to have, but versions and version ranges should be different classes because they're really different (and complementary) things.

[lizmat]

versions and version ranges should be different classes because they're really different (and complementary) things.

Agree. But the only thing I can see happening atm, is to make Version objects that are implicit ranges (aka, with a *, - or +) a subclass of Version, as a VersionRangeclass.

[Leont]

Agree. But the only thing I can see happening atm, is to make Version objects that are implicit ranges (aka, with a *, - or +) a subclass of Version, as a VersionRangeclass.

Except the relation is really more the other way around: Any version is also usable as a version range, but version ranges usually aren't usable as a version (e.g. they can't sort/compare, which is essentially the whole purpose of versions).

They should be different classes, with a trivial VersionRange(Version) constructor/coercer

[lizmat]

Well, then we get to Range with Version objects. And that's another can of worms, with iterable and non-iterable Ranges.

[Leont]

Well, then we get to Range with Version objects. And that's another can of worms, with iterable and non-iterable Ranges.

They're also awkward because then you'd need an infinite version value (for the maximum value). Or to represent exclusions. It needs a separate class really.