Unable to run Livebook with Elixir v1.18.0-rc.0

[eksperimental]

Connecting runtime failed - the node uses Elixir 1.18.0-rc.0, but ~> 1.17.0 is required

Connect the session to an already running node and evaluate code in the context of that node. The node must run Elixir ~> 1.17.0. 

I know the requirement has been lifted to "~> 1.18.0-rc.0", but I am still running the latest Liveview release, and I get this error when my project's Elixir version is 1.18.0-rc.0 and the @elixir_requirement version for the built that I am using was "~> 1.17.0"

Due to the backward compatibility of Elixir versions, would it make sense to soften @elixir_requirementto "~> 1.18", this way it will work when a new minor version of Elixir comes out?

[josevalim]

We cannot guarantee that code that we expand in one node for Elixir v1.18 will work on v1.17 or vice-versa. There were actually issues in the past, hence the strict version.

[josevalim]

One option is to make this a warning but let the user continue at their own risk. Thoughts @jonatanklosko?

[eksperimental]

We cannot guarantee that code that we expand in one node for Elixir v1.18 will work on v1.17 or vice-versa. There were actually issues in the past, hence the strict version.

So this means that Livebook will only work for the current minor Elixir version supported?

[josevalim]

It means you need to run Livebook in the same version as the node you connect to. So this may mean you will need to install and run Livebook in your CLI instead of the desktop app.

[jonatanklosko]

We cannot guarantee that code that we expand in one node for Elixir v1.18 will work on v1.17 or vice-versa. There were actually issues in the past, hence the strict version.

@josevalim FTR the initial reason we introduced the check was to ensure minimal version required for the new Elixir features the runtime code relies on (#1654), we were checking against requirement from mix.exs. We strictened the check recently to match the same minor as the running version.

Since we bumped the requirement in mix.exs, we still want to enforce that for the runtime (we could have a separate requirement there, but in most cases we bump the requirement specifically because of the runtime). So at the current moment we want to show that error either way. We can consider a warning in the future though.