Skip to content

RFC 0030: Forward Compatibility Policy - #30

Merged
straight-shoota merged 4 commits into
masterfrom
rfc/forward-compatibility
Sep 1, 2026
Merged

straight-shoota merged 4 commits into
masterfrom
rfc/forward-compatibility

Conversation

@straight-shoota

@straight-shoota straight-shoota commented Aug 25, 2026

Copy link
Copy Markdown
Member

@straight-shoota straight-shoota changed the title RFC: Forward Compatibility Policy RFC 0030: Forward Compatibility Policy Aug 25, 2026
@crysbot

crysbot commented Aug 25, 2026

Copy link
Copy Markdown

This pull request has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/rfc-0030-forward-compatibility-policy-30/9112/1

@paulocoghi

Copy link
Copy Markdown

It seems too long the time frame of 8 releases (2 years) of forward compatibility.

In my point-of-view, reducing it is mostly positive for the language. Learning from what Go and Rust do, a time frame of 1 year looks more balanced.

> [!NOTE] Backwards Compatibility
> This policy does not affect the [_Backwards Compatibility_ policy]:
> Any compiler of the 1.x release series can still compile a program written for 1.0.
> That includes being able to build a 1.0 compiler from any future compiler of the 1.x series.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this imply that we must not drop LLVM 11 support for the rest of Crystal 1.x, since Crystal 1.0 only supported up to LLVM 11.1?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe so, yes. We guarantee that existing APIs continue working in future minor releases. The LLVM bindings are part of stdlib, so they need to maintain compatibility. And if stdlib does, the compiler can, too.
However, we do not explicitly specify whether or how stability guarantees apply to third party library bindings, especially when those libraries are no longer maintained.

Anyway, that's unrelated to the forward compatibility policy.

@ysbaddaden ysbaddaden Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though unrelated to forward compatibility, that's a very good point about backward compatibility. If the compiler can't assume LLVM 18 despite being available in the bootstrap version, that would be a problem.

Hm, the code for Crystal 1.0 supports LLVM 11 for the code it will generate, and it will use the LLVM bindings from the 1.0 release, so whatever if the current compiler uses LLVM 22 and the current compiler doesn't support LLVM 11 anymore: the newly compiled Crystal 1.0 should still compile & work?

@beta-ziliani beta-ziliani left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, thanks @straight-shoota for putting it forth!

@straight-shoota

Copy link
Copy Markdown
Member Author

@paulocoghi Maybe you're right and a shorter support window would be even better. But I believe two years are already pretty good. Let's start with that and figure out how things go from there.
It's already a huge step from the current situation of 5+ years of forward compatibility.

@straight-shoota
straight-shoota merged commit 296d2b2 into master Sep 1, 2026
2 checks passed
@straight-shoota
straight-shoota deleted the rfc/forward-compatibility branch September 1, 2026 12:18
straight-shoota added a commit to crystal-lang/crystal that referenced this pull request Sep 3, 2026
Restrict forward compatibility CI to cover only the eight most recent releases.

Implements crystal-lang/rfcs#30
straight-shoota added a commit to crystal-lang/crystal-book that referenced this pull request Sep 4, 2026
straight-shoota added a commit to crystal-lang/crystal that referenced this pull request Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants