crystal-lang / shards

Dependency manager for the Crystal language
Other
763 stars 100 forks source link

Bump supported Crystal version to ">= 0.35.0" in shard.yml #463

Closed Sija closed 3 years ago

bcardiff commented 3 years ago

I don't agree with >= version restrictions. Compile with --ignore-crystal-version until 1.0 is out and ecosystem is updated.

straight-shoota commented 3 years ago

But it is compatible with 0.35.0 and 1.0 (at least 1.0-pre). If not open ended, it could at least be something like crystal: >= 0.35.1, < 2.0.

I am strictly against forcing to use --ignore-crystal-version everywhere as per https://github.com/crystal-lang/shards/issues/413#issuecomment-727633776. It that's supposed to be the solution, it would be much, much better for everyone to just not enforce Crystal versions at all.

Sija commented 3 years ago

@bcardiff As far as I understand, shards are and will be compatible with crystal >= 0.35.0, right? I don't agree with doesn't sound like an argument but your private opinion, no offence - and it seems a bit far away from welcoming community standards and meritocratic approach, which I hope you agree with as beneficiary.

bcardiff commented 3 years ago

@Sija I believe I have expressed my concerns in posts and issues already why not having and upper limit in the stated crystal version is a practice I won't encourage.

@straight-shoota proposal is better in this regard. Yet we need first to release 1.0-pre1 and to everybody to honor that no more breacking changes are wanted in 1.x to make the statement of for < 2.0. Even small breaking changes that are motivated by valid cleanups and improvements will break that statement.

Of course, there are ways of disregard whatever version restriction is stated. You need to put whatever you want in lib and the compiler lookup path will use it. But I prefer for version restrictions to mean something, even if they are more conservative.

straight-shoota commented 3 years ago

I don't think you have expressed your concerns enough. At least I don't follow them. And there was no response to the latest counter arguments in #413.

Around major releases with breaking changes, a version restriction is always subject to being incorrect, wether it's overspecific or underspecific. Being conservative IMO has mostly ideal value, but practically it's relatively irrelevant whether the stated version compatibility is factual. We're only talking about a development version here. It just makes using it harder for everyone.

I don't think we need to release 1.0-pre1 before stating that shards is compatible with 1.0. At this point it should be a given that the next shards release will definitely be compatible with 1.0.