Require semver as official versioning policy about shards HOT 4 CLOSED

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.

from shards.

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)

from shards.

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.

from shards.

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.

from shards.