Fix shard crystal version in crystal init

[xendk]

The crystal: x.y.z format is described as legacy and discouraged in the shards docs, so update it to use the version constraint.

[Sija]

Wouldn't more conservative ~> be safer by default?

[xendk]

I didn't really consider alternatives, I just made it explicitly use the constraint that the shards docs says it uses for plain versions:

There is a special legacy behavior (its use is discouraged) when just a version number is used as the value: it works exactly the same as a >= check: x.y.z is interpreted as ">= x.y.z"

But now you mention it:

I created a project back in April (according to the file timestamps), which added crystal: 1.7.3. So if the using the ~> constraint, it would already be outdated by two minor releases.

My feeling is that the intention of most users would be to be compatible with all crystal versions until the next major version.

[Sija]

My feeling is that the intention of most users would be to be compatible with all crystal versions until the next major version.

If so, then the proper constraint would be ~> x.x.

[xendk]

Not that I disagree, but that's a change of behavior, not just fixing it to not use a discouraged format.

It's also a tad more involved. Currently, it's just using Crystal::Config.version which is the full version. To get the version needed for ~> we'd need either some string hackery (which seems wrong to me) or extend SemanticVersion with a to_s-like method to render the given version with a given granularity, so we can do something like SemanticVersion.parse(Crystal::Config.version).bump_major.to_s(:minor).

But I'd prefer a nod from a core team member that this change is acceptable before trying my hands on an implementation.

[Sija]

Sure thing, I agree it's a bit more involved solution, just mind you, that for the all crystal versions until the next major version part to hold, you'd need to use >= n.n.n, < n.n constraint, which IIUC is practically the same as ~> n.n.

[xendk]

Oh, but of course there's a test that needs fixing. I'll look at it tonight.

[xendk]

There.

[xendk]

Oh, I didn't notice the failure there... But doesn't seem to be related to the PR?

[straight-shoota]

No, that failure is unrelated. Interpreter specs are flaky.