Proposal: publish a release candidate 1-2 weeks before releasing breaking changes

[paulcsmith]

Hello Crystal team! Congrats on a new release 🎉

I have an idea for easing the transition to new releases.

Issues with the current process

The main issue is that different platforms get official releases at different times. For example, right now if a Linux user installs Crystal they are likely to get 0.27, but a Mac user using Home-brew installs they'll get 0.26.1

So if I release a new version of Lucky or some other library with support for 0.27, it will break Mac users on 0.26.1. Of course Mac users can upgrade but it requires gong around homebrew and most people will just give up or wait for homebrew. If I don't update Lucky or some other library then Mac users can use it, but Linux users can't w/o downgrading.

Proposed solution

My proposed solution is to release a release candidate a week or two beforehand. The release candidate would also be available on homebrew.

This way when the final version comes out and it is inevitably delayed on homebrew (which is to be expected and totally ok since they need to verify everything on their end) library owners can suggest users install the release candidate with homebrew.

This will make it so library owners can update their install docs to let Mac users know to install the release candidate with homebrew and Linux users can install the latest using the usual means. Once Homebrew is up-to-date with the official release, library owners can tell Mac users to install the official release again.

I'm not sure I explained this clearly, so if it doesn't make sense, let me know

[paulcsmith]

Another idea I had right after posting this: could we release the Linux version and blog post once homebrew accepts the latest version? My assumption here is that it is easier/faster to release a blog post and linux versions and is under Crystal team's control so this may be a way to sync things up as well. But my assumptions may be totally wrong here :)

[straight-shoota]

I fear this proposal would only complicate things more and doesn't really solve anything. Even with a release candidate, there will inevitably be version mismatches, where the current version of a library is targeted at a different compiler version than the one available. Or even two or more libraries that are supposed to be used together might target different compiler versions.

I don't think a release candidate can add any improvemen. It probably makes it only more confusing because there are more compiler versions in play.

With a language that is constantly changing, it is to be expected that there are breaking changes from time to time. And not only package managers but also libraries need to catch up to the latest releases.
If you're always using the latest development version of a library, there is no way avoiding failing builds from time to time because of breaking changes in the compiler, stdlib or other libraries.
In order to avoid this, the solution is to lock compiler and library versions and only upgrade when all dependencies work with the current compiler release.

[j8r]

There are a multitude of OS with their package managers, that bring new releases at their own pace.
The only native solution is to have a repo for each one to control the release date, and deploy them simultaneously, but this is heavy maintenance wise.

I don't see any problem particular to Crystal, every language/application face this issue.
One convenient solution I see is using Docker, the users can now run it in major platforms.

[paulcsmith]

Maybe part of the problem is that in the shard file you can put a crystal version, but it doesn't actually check anything or raise a warning. So people don't know what to do.

I don't mind the breaking changes, what I think is a problem is that people often don't know what to do.

I see what you mean about having lots of package managers, but we need some way to make it clear to users what is wrong. Right now they just see compilation errors because of missing methods and don't know what to do.

Maybe if crystal/shards checked the version defined in shards.yml and raised/warned that would be enough. As it stands now I have to manually respond to these issues and it gets tiring. Automating it with shards.yml would be awesome! Thoughts?

[paulcsmith]

@j8r I agree it is not specific to Crystal, but Crystal has a lot of breaking changes. I think that is good because it is rapidly improving, but it is problematic because we don't have a good version manager or a good way of warning users when they are using unsupported versions of Crystal with a library.

I think we need to either make the releases (at least for the most popular package managers) in sync, or have some way of helping users figure out they need to downgrade w/o them having to ask in chat/stack overflow

[paulcsmith]

I also like a release candidate because it makes it easier to test w/o going through so many hoops. That would be really cool! Right now you can't brew install it so most people don't bother. I bet if there was a release candidate on home-brew that was easily installable we'd have more people testing and getting ready before the official release, which would be awesome!

[j8r]

You could tell the users to use https://github.com/pine/crenv ? There are also nightly builds.

[straight-shoota]

I think we need to either make the releases (at least for the most popular package managers) in sync,

I don't think that's an option. The Crystal team can't possibly sync releases in package managers it doesn't govern. Even if it was practically possible, it would unnecessarily delay releases in all but the slowest-to-adopt package manager. That'd be nonsense.

if there was a release candidate on home-brew that was easily installable we'd have more people testing and getting ready before the official release

We don't necessarily need a RC for that. Nightly builds are totally fine. And it actually works like a charm on CI using Docker (see Using CircleCI 2.0 for your Crystal projects). We just need a way to make nightly builds easily available through package managers (this is also discussed in #5836).

[paulcsmith]

Ok sounds like this is a no go. I'll go ahead and close it