Motivation

I think it is important to allow shards to work and deal with dependencies that will require some range of language/std-lib version to work with. Up until now we frameworks usually force to run on Crystal latest only for convenience as the ecosystem mature and gets bigger.

Current status

Currently SPEC says:

The last known Crystal version that is capable to compile the Shard (String).
Purely informational.

• I've seen shards with no crystal version key
• I've seen shards that do not change the crystal version in the shard.yml
• I use it in crystal-db as the minimum required version

Thoughts

I think we should enforce a different semantic on the crystal version mentioned in shard.yml.

For a given shard release, if we restrict that it will work with crystal <= upper_bound this means that:

• shards resolver could directly discard old releases that will not work with the current crystal version used in the project
• will push the community to keep an eye and maintain the shard more thoroughly once a crystal > upper_bound is released.
  • Some of the updates might by lifting the upper_bound if everthing is fine.
  • might delay the whole ecosystem to come up to date and be available to the latest crystal version.

For a given shard release, if we restrict that it will work with crystal >= lower_bound this means that:

• shards will be able to avoid upgrading the shard beyond what is supported in the current crystal version used in that project. (this is important if the current crystal version of the project is not the latest crystal release).

Depending on the upper_bound chosen it might become a burden for the ecosystem to upgrade things on every minor crystal release.

Picking an upper_bound should balance between a guess on what could happen and committing to a maintenance for lifting.

Although shards packages are not required to adhere to semver, the compiler and std-lib could / should.

Proposal

Even if we don't implement the whole logic now in shards, it is good to state what is the semantic of the crystal key.

If we assume Crystal & std-lib will adhere to semver then we can push the burden of forcing the ecosystem to republish shards on mayor releases only.

So, I would like to propose that crystal: x.y.z be treated as ~> x.y, >= x.y.z (ie: >= x.y.z, < (x+1).0.0). When x >= 1 this is what semver should guarantee, right?

Implementation detail: bundle/molinillo seems to use the ruby version as another dependency. We can do the same and use some magic string like crystal or crystal-lang/crystal as a dependency name in the algorithm. Even if multiple expressions like ~> x.y, >= x.y.z are currently not implemented in shards, we can fix some semantics in crystal: x.y.z, different from the dependency section, for convenience.