Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
This is a meta issue to track the progress of releases in Elixir. The goal is to include minimum support for releases, then add user conveniences, and then finally work on hot code upgrades with relups and appups.
The goal here is to add releases to core without many bells and whistles:
The goal here is implement user facing features:
I have spent most of the week studying hot code upgrades and building prototypes and I have decided to not include them as part of Elixir Core for now (at least for Elixir v1.9). The rationale is that they are still very complex, error prone and opinionated in a way that whoever is performing them needs to be aware of many of the decisions taken. For example, the distillery guides on appups (which is a part of hot code upgrades) covers many of those topics.
We are not saying they will never be part of Elixir but not for now. This can be a good opportunity for the community to build on top of what Elixir provides.
I wrote an extensive section on the docs about hot code upgrades which I reproduce below for convenience that explains this rationale and guides users.
Erlang and Elixir are sometimes known for the capability of upgrading
The reason we don't provide hot code upgrades is because they are very
In a hot code upgrade, you want to update a node from version A to
You add this process as part of your supervision tree and ship version
If you to perform a hot code upgrade in such application, it would
Now you can proceed to list this process in the
Overall, there are many steps, complexities and assumptions made
Although not achieved out of the box now, I think it is important to not only support them 'soon' but also have an easy way to test (ExUnit addition?) to make sure a given application 'can' be hot upgraded safely and for this to become part of the standard templates. Even if the feature is not used by an end-project this still helps ensure that program has a sense of 'migrations' and code_change's defined properly to reason about the information.
As for a more Elixir'y style, what about a set of migrations that migrate from version to version that define code_change functions and things that appup/relup's need and thus can be generated from that Migration code (ala
The main issue I think would happen if its not supported 'soon' in the
Those are very good points @OvermindDL1. I particularly like the ExUnit idea.
I think it reinforces the point that it needs a lot of work and exploration before it gets to fully be part of core. We can also do it in steps too. For example, we can include a way to define
But I also think we need to consider that, even if those functionalities are in Elixir, some people simply won't define the
It is quite easy to automate a lot of the
There are a number of people that have used hot upgrades with Distillery, and aside from some issues that were bugs in Distillery, I think the foundation it provided was better than having to do it all by hand.
I don't think hot upgrades are important to have right now, but I do think that there is a path towards supporting them in a way that simply takes away a lot of the manual work one has to do. In the near term, tools which build on core can provide hot upgrades (i.e. Distillery would likely continue to provide that capability as an additional feature).