Closed kachick closed 3 years ago
Well I guess that's where different philosphies collide.
I wouldn't place an upper restriction by default because it's likely that a shard's code will just work with 2.0 as well as it did with 1.0. Yes, 2.0 will bring some breaking changes, but the goal is still to keep that as minimal as possible. Crystal 2.0 won't be a completely different language and break every Crystal code out there. Looking backwards, some of my shards written for ancient versions like 0.26.0 or so still work with 1.0. There have been a lot of releases with breaking changes since then to the language and stdlib. But that doesn't matter if a shard doesn't use the broken features.
Currently we see a lot of issues with shard dependencies not installing for 1.0 just because they don't state to be compatibile. If you install with --ignore-crystal-version
, everything works. But that shouldn't be the solution every time a new major Crystal release happens and shard maintainers don't get to update their shard dependencies quickly.
Agreed with your comments! Thanks for the polite answer 🙏
I'm a newbie in crystal-lang and the tools around them. 😅 So this PR might be just a question...
As far as I know, Crystal made many changes the specs so far. So planning
2.0.0
will contain other many changes? Then the versioning including< 2.0.0
might be robust? I sawshards
specifying as it in own shard.yml https://github.com/crystal-lang/shards/blob/addc26a3f22fee9fccb01cbb3e8878bef02d4295/shard.yml#L15 👀I know
examples
does not meanrecommended
. But it often spread into wide, I think. How about to write this in example?