maintenance / EOL policy?

[noraj]

Is there (or plan to be) a {release life cycle, maintenance branches, end of life (EOL), support version} policy?

On the release page (https://crystal-lang.org/releases/) we can watch which version was published and when (similar to Ruby https://www.ruby-lang.org/en/downloads/releases/) or even new version announcement on the blog.

But I didn't find any EOL announcement for some version branches (similar to ruby https://www.ruby-lang.org/en/downloads/branches/), saying which will receive bug or security patches and which is not supported anymore.

But maybe Crystal has some sort of cutting-edge rolling release policy, like Arch Linux, so only the very latest version is supported? But I didn't found a documentation page explaining that either.

So what's the maintenance / EOL policy of Crystal?

[Blacksmoke16]

I brought this up in the past internally, and if I remember correctly we don't really have an established policy on it. Mainly since there hasn't been any major bug that would require issuing patch releases for past releases.

Bug fixes have always just been released for the latest minor and never really back ported, so IMO it's closer to Arch's approach where only the latest version of a package is supported. But for a major bug/security issue its definitely not off the table backporting it to the last few releases.

[straight-shoota]

Yeah there are some scattered bits about this in different discussion threads. But it makes sense to write it all down as public information.

In contrast to Ruby, our minor releases are not breaking backwards compatibility. So it should always be possible to upgrade to the latest release and we'll usually only release bug fixes for the most recent minor. The equivalent to Ruby's release branches would be based on the major version only in Crystal. So the 1.x branch is currently in normal maintenance. All 0.x releases are EOL. When we reach Crystal 2.x, we might continue with that or immediately drop 1.x to security maintenance only (we'll figure that out once we get there).

[noraj]

Yeah there are some scattered bits about this in different discussion threads. But it makes sense to write it all down as public information.

Please do. With a written policy I would be able to PR to https://endoflife.date to add Crystal. It would help in integrate Cyrstal in many update tracking systems.

In contrast to Ruby, our minor releases are not breaking backwards compatibility.

I recently updated a project that was using Crystal 1.7.3, and when I read the 1.8.0 changelog, I saw a lot of (breaking-change) label.

The equivalent to Ruby's release branches would be based on the major version only in Crystal. So the 1.x branch is currently in normal maintenance. All 0.x releases are EOL. When we reach Crystal 2.x, we might continue with that or immediately drop 1.x to security maintenance only (we'll figure that out once we get there).

Totally makes sense.

[straight-shoota]

Nice, I didn't know of https://endoflife.date 👍

when I read the 1.8.0 changelog, I saw a lot of (breaking-change) label.

Of course any change - even bugfixes - has a potential to break existing code. Maybe somebody depended exactly on that buggy behaviour 🤷 We're quite explicit about highlighting changes which we consider to have a (slighly) heightened risk of breaking someones code, even if it concerns experimental and unsupported features for which there are no stability guarentees. That explains the many labels.

Many of these breaking changes in 1.8.0 are just deprecations. The code will continue to work just fine but removal is exepected in the future, so we're already marking it as breaking now that the decision has been made. (Nowadays we're mentioning deprecations in their own section without the "breaking" label)

Other changes marked as "breaking" only apply to stdlib or compiler features which were not intended and documented for public use and thus we never promised stability. This is just an extra service to let people who still use these things on their own risk know about potential issues (and even those are typically just affect some edge cases).

It's not possible to exclude any and all breaking changes but we're commited to avoiding any explicit breakages and expect all well-defined Crystal code written for 1.0 to continue building for any future 1.x release.

[straight-shoota]

@ysbaddaden Pointed me to https://hexdocs.pm/elixir/compatibility-and-deprecations.html which seems like a good template for a release policy page. I'm not too fond about merging a list of specific deprecations because that's a different concern. We should have that for Crystal as well, but as a separate document.

[straight-shoota]

I posted a proposal at https://github.com/crystal-lang/crystal-book/pull/756

[crysbot]

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

https://forum.crystal-lang.org/t/rfc-0007-event-loop-refactor/6812/4

[straight-shoota]

Resolved by https://github.com/crystal-lang/crystal-book/pull/756