A few incompatible changes to language semantics were introduced between 0.36.1 and 1.0.0, and we do not want to repeat the same when 2.0 drops. For breaking changes initiated by Crystal code, the @[Suppress] annotation is one possible solution, but the same idea won’t work for language-level change…

Thanks for bringing this up. I feel it’s a bit early to start discusing this, but nevertheless it’s good to have this in the back of our heads. I wasn’t around when the transition between 0.36 and 1.0. But I think the transition between 1.X and 2.0 is a different one, since I wouldn’t expect people…

I don’t think this is too early. We already have a couple of breaking changes in the pipeline that we’ll probably want to have for 2.0. It would be good to have a plan how to move on. We shouldn’t have to wait up until shortly before 2.0 to get them merged somewhere. Also, not all changes are hard …

Ah, thanks for the clarification. But then, I’d prefer to discuss specific things, like, what is super important that can’t wait for 2.0? Or that isn’t just Deprecateble in 1.X?

I don’t think it’s about being too important that we couldn’t wait. But pulling breaking changes up gives more chances to find potential issues with them, makes it easier to partially migrate have people update (or start) their code bases with future-proof semantics. A specific change that we could…

Has the core team discussed something like Editions before, (found in Rust) as a graceful, opt-in rollout strategy for new features/semantic changes to the language?

Nope. I’m not sure how they do the separation per crate, but I expect that would be rather difficult to do in Crystal.

[image] beta-ziliani: Ah, thanks for the clarification. But then, I’d prefer to discuss specific things, like, what is super important that can’t wait for 2.0? If nothing else, it would be really nice to have a branch that is easy to install that consists of stuff aimed at 2.0 as well as havi…

What you suggest sounds like having multiple development branches in parallel. I fear that it would be hard to keep track of what’s happening where and cause a lot of confusion. At the current size of the project, I don’t think it is feasible to manage.

In the last core team meeting we decided to keep and maintain just one branch, adding the new, breaking features with opt-in command-line flags. Then, the version 2 of Crystal will simply consist of the compiler with some of these turned on by default.

Continuation on compatibility profiles: Compatibility profiles for CI tests opened 01:53PM - 05 Jan 22 UTC (UTC) [HertzDevil] HertzDevil topic:infra…

Ensuring smooth language changes for 2.0

Crystal Contrib

Topic		Replies	Views
When crystal-lang 1.x will be released? Help & Support	42	5366	August 9, 2024
My 2022 Crystal Wishlist Community	19	3096	March 11, 2022
Crystal in 2020 News	32	3594	April 4, 2020
Why people leaving crystal? Community	95	13233	July 21, 2023
Crystal 0.31.1 has been released! Official	35	1924	October 11, 2019

Ensuring smooth language changes for 2.0

Related topics