Elixir v1.11 will be released in October 2020

Hi! :wave:

I hope everyone is well!

The Elixir team releases new versions every 6 months, typically every January and July. However, since many of us may have more than usual on our plates lately, we will be postponing the next Elixir release by 3 months.

Even though Elixir releases are backwards compatible and we were on track to release a new version in July, new Elixir versions always push some amount of work downstream, for example, to library authors that need to upgrade CIs and ensure everything runs smooth (which is usually the case). This is why we decided to postpone. It also gives us an opportunity to evaluate if every 9 months is a better release frequency than every 6 months.

Therefore, Elixir v1.11 will be released in October 2020. If there are any important bug fixes, we will continue releasing patch versions for Elixir v1.10. On that note, the latest Elixir v1.10.3 is already compatible with Erlang/OTP 23.

Thank you and stay safe!


It also gives us an opportunity to evaluate if every 9 months is a better release frequency than every 6 months.

:+1: This is a great idea. Every 6 months might have been the correct cadence while the language was being developed but now that it’s “done” (and I love that decision btw) a slower cadence seems appropriate to consider.




Stability is a feature. Happy to keep it that way.


Great news. 1.10 release was a hard one (IMO comparable to 1.7 and 1.4) on https://github.com/elixir-lsp/elixir-ls and https://github.com/elixir-lsp/elixir_sense. Some things are still broken on as of 1.10.3 and there are initial reports of further breakage on 1.11-dev.

Right. We need to find a long term approach to bring some of those features into Elixir, so you don’t have to rely on private APIs. Part of it was done with compilation tracers but there is most likely more.


Have you done a talk or a writeup of how these are being brought into Elixir core?

No because there is nothing being done besides it being something we would like to have some day. :slight_smile:

1 Like

I’m just trying out the new xref improvements and while it’s great to be able to see exactly which modules will be recompiled it’s still quite a bit of manual work to find out why a certain module is even linked to the module, which has a compile time dependency to some other module, which will be recompiled. It would be really great to also have means of requesting all the paths between file x and file y.

Thank you for giving master a try @LostKobrakai! However, I am afraid I cannot really act on your feedback. Can you say which commands you tried? Which parts of their output was confusing? You can also find the graphs between two files by using one of them as source or as a sink and then looking at the graph.

I did use mix xref graph --sink …/notifications.ex --label compile to find out a file where I implement Phoenix.Param for some schemas will be recompiled.

└── lib/connect/externals/sales_responsible.ex (compile)

Generally those those two files shouldn’t have anything to do with each other. But it seems there’s some level of transient dependency here. But it’s not shown completely. sales_responsible.ex aliases team.ex (an ecto belongs_to relationship; I tried Module.concat on it and it removes the dependency) and from there it becomes fuzzy where exactly the path to notifications.ex actually is. I can’t really remove the compile time dependency here as a protocol implementation does require it, but I’d still like to clean up my mess of interdependencies at the layer between notifications.ex and sales_responsible.ex.

The graph is param -> sales_responsible -> notifications. There are two options here:

  1. xref is collapsing transient deps: you can verify this removing the --label compile option and finding this path in the graph

  2. xref is correct - that’s the dep but you can’t see how it happens and I can’t help without seeing the files either

1 Like

What I’ve been doing now is, as you suggested, dropping --label compile and going through the results doing this:

  • search for dependency file at the root:
    e.g. ^lib/connect/externals/sales_responsible.ex
  • Take all dependencies and repeat with those files:
└── lib/connect/teams/team.ex

Doing that I was able to find this (one branch of a handful) out of the 2000 line long xref result.

lib/connect/externals/sales_responsible.ex (compile)

Having that work be done by xref on the actual graph it (probably) builds and outputting a dot graph or text based format of just the paths between lib/connect_web/protocols/param.ex and lib/connect/notifications/notifications.ex is what I’d be interested in. Doing mix xref graph --sink …/notifications.ex --format dot without such a filter results in a non-comprehensible graph.

The middle part of lib/connect/externals/sales_responsible.ex -> lib/connect/tenancy/invitation/manager_invitation.ex btw are only ecto relationships. So those still can be problematic even without them being compile time dependencies anymore.

Edit 2:
The likely best solution was to breaking up a circular dependency between lib/connect/tenancy/invitation/manager_invitation.ex and lib/connect/tenancy/invitation.ex.

You can now specify both --source and --sink in master, allowing you to see all possible paths between two files.


That sounds great and like what I was asking for, though I’m not yet seeing it on master on github.

Apologies, pushed now.


Just tried it out. It still shows a a bunch more files, but it listed this in the very beginning, which is basically what I had above (the last dependency is different because of the refactoring I did today):

├── lib/connect/externals/marketing_responsible.ex (compile)
│   └── lib/connect/teams/team.ex
│       ├── lib/connect/teams/member.ex
│       │   ├── lib/connect/teams/team.ex
│       │   └── lib/connect/tenancy/member.ex
│       │       ├── lib/connect/tenancy/invitation/manager_invitation.ex
│       │       │   ├── lib/connect/tenancy/invitation.ex
│       │       │   │   ├── lib/connect/notifications/notifications.ex

Maybe there could be a shortest path only option, but the text format seems to start with that one anyways.
The dot graph is still a bit big and doesn’t feel useful in my case yet, but it is by far more usable than before and combined with the text format your changes are already really helpful.