Require semver as official versioning policy

[ozra]

Officially stating that crystal modules/packages should follow semver versioning (http://semver.org) would greatly increase stability in dependency managing.

Version matching becomes much more deterministic and it's simple to lock in on a version specifically, allow just patch updates, feature updates, or even breaking updates at will.

The project structure of crystal solutions seems to be rather well set and thought through already, so this is the logical thing to do to avoid dependency hells.

Following the semver rules are both simple and rewarding, and there's no benefit to ad hoc versioning schemes.

[ysbaddaden]

I like the way rubygems states this (buried in documentation):

The RubyGems library itself does not enforce a strict versioning policy, but using an “irrational” policy will only be a disservice to those in the community who use your gems.
http://guides.rubygems.org/patterns/#semantic-versioning

Shards does the same: enforce nothing, expect developers to gear toward a sane versioning.

[ozra]

Ah, I see, too bad. I think this is one of those things most of us developers don't spend much thought on and where a good outspoken common guideline can really benefit a package eco system, while leaving your mind free to what "really matters" (the app/lib code). Much more than even a common syntax in a jointly used language.

Well, as long as one can write something along the lines of some_pkg @ 1.2.* semver matching can be exploited fully (since specifying version ranges via lt(e)/gt(e) has next to no need when using semver, except for in edge cases where a developer has mistakenly released a version of a dep breaking the rules and it actually causes problems [breaking changes without major increase, or new overloads gaining precedence with only patch increase, thus breaking] and needs to be worked around explicitly)

[ysbaddaden]

That being said, semver is fully supported, and is the de facto form for release numbers. All the operators have been implemented: =, >, <, >=, <= or the ~> for instance.

I'm just not enforcing the x.y.z scheme, and do allow x.y just like a.b.c.d.e to be release numbers. There are no reasons to not support them, and they work with the above operators.

[ozra]

It does make sense, that it is de facto, because, as you mention, it's not an impossibility that a specific project actually may benefit from, say, an additional semantic unit, using four parts.