chore: define version for dependencies

[2-towns]

The dependencies are defined in Nimble without specifying versions, which is problematic as it can break dependency resolution for projects that rely on this library.

This is the case with the last version of nim-stew.

[arnetheduck]

we generally don't specify upper ranges on dependencies since this more often than not is obnoxious to users and breaks resolution for no good reason, specially on 0.x-deps.

This is optimistic versioning, where we only add upper ranges once it is known for certain that something broke, in the cases where the breakage cannot be resolved in the downstream user of the package (typically the "end application").

[arnetheduck]

Seen in a different way: upper ranges only make sense for packages that explicitly state they follow semver, which these packages don't (ie like python, Nim has a flexible approach to versioning in its ecosystem).

[2-towns]

Hum got it, thanks for the explanation.

So if this package does not follow semver, let's say that the next version 0.2.10 contains a breaking change. Is nimble smart enough to keep the 0.2.9 in my project ?

[arnetheduck]

No, it's not (I've thought about a "try all versions" style of command that would discover such breakage - would be neat, for autoversioning).

fwiw, the >= constraints are useful - feel free to add them to this library. They should be set to the lowest possible version that works for n-j-s.

Due to how symbol lookups are done, there are very few ways you can change code in nim that is guaranteed not to break downstream code - ie ABI stability is pretty hard to achieve.

The reality of nim is thus "mostly works but might break a few things" and there's no way to express that in semver - specially for libraries like stew which are really collections of libraries where most usages are not affected.

[2-towns]

Okay thanks a lot for those details