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.
It also gives us an opportunity to evaluate if every 9 months is a better release frequency than every 6 months.
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.
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.
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.
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.
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.
Edit:
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.
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):
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.
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.
