Preparing for 1.1.0

TL;DR freeze will start this Saturday 19th

We want to share the news of the imminent plan towards the 1.1.0 release. We are committing to a 3 months release, thus we except to release it in the first days of July. Before that, we will have a freeze period—starting this Saturday—of approximately two weeks. During this period there will be no merging in the main branch of new features, only allowing bug-fixes strictly related to the release. Once the 1.1.0 is officially released, we’ll continue as usual.

We are purposely delaying a few PRs that might introduce mild breaking changes for the next milestone (1.2.0), in order for the community to have more time to adapt to these (e.g., #10805).

We would very much appreciate hearing from you of any issue that the new release might bring. Note that you can use the nightly builds of OBS to check how your program/shard works with the latest development.

22 Likes

Will 1.1.0 support the m1 macs by chance?

On our side, aarch64-darwin has already been supported since 1.0.0. As far as I am aware, all that’s currently missing is packaging. That was stalled because of an LLVM bug. But after this has been identified and can easily be patched, this should be resolved shortly.
Since it’s a packaging issue, this is not tied to a specific Crystal release. A package with patched LLVM can be published independently of a release. We could even still release a 1.0.0 package with M1 support.

3 Likes

Any plans for 1.0.1?

Also, do we verify manually that 1.0.0 stable can compile 1.1.0? I think there’s a good CI opportunity because it seems the current GHA workflows always check out from master instead of latest-stable.

I think 1.1.0 should be fully backwards compatible, so I can’t see a difference between that and 1.0.1. Or do you think there would be a difference?

Instead of a freeze, have you considered using a release branch? This would allow developers to continue contributing, while isolating the release.

Exactly, what do you have in mind @HertzDevil ?

Yes, we considered using a release branch. But given that usually PRs aren’t merged right away, and that the expected freeze window is short, we decided it wasn’t necessary to branch. We might change this in the future if we find it problematic.

3 Likes

If the freeze window is short, not using release branch is very good way to avoid bugs introduced by merges and distribute conflict solving to the patch authors :slight_smile: . But one day have release branches will be inevitable.

2 Likes

Now that we’re in the freeze period, we ask everyone to test the current nightly builds as release candidates of the upcoming 1.1 release. Please report any issues found at Issues · crystal-lang/crystal · GitHub

4 Likes

Don’t know what patch caused this but Crystal 1.1 (71d6e9b63fa06b3ace5207fc0ea1f1d20a2c6089) reduced my binary (stripped, release mode) size in almost 20Kb, this is 1.187% saving :scream:

Crystal 1.0: 1387240 bytes
Crystal 1.1: 1370768 bytes

Both compilers using LLVM 10.0.1.

2 Likes