I believe that an already-installed dependency will be updated as part of a hot-code upgrade of your own main app.

This will trigger all of the loaded GenServer’s code_change/3 methods to fire.
There are three possibilities:

1. The GenServer has no custom implementation of code_change/3 which means that the default one is used. This one keeps the state the same. This does mean that if the structure of the state that if the new version of the GenServer expects the state to have a different shape, that it will probably crash once the next event arrives. Depending on how it is supervised it will restart after, but it might result in a temporary crash and some lost state and/or a lost event.
2. The GenServer has a custom implementation of code_change/3. Assuming it is implemented correctly (and does not raise), the GenServer will be upgraded perfectly. Note that not many libraries implement custom code_change/3s for their servers.
3. The GenServer has a custom implementation of code_change/3 which raises an exception. This prevents the hot-code upgrade of this particular OTP application (and usually your hot-code upgrade as a whole) to finish; everything will stay at/revert to the previously-used version. This is for instance commonly done for modules containing NIFs (natively-implemented functions) because making native code backwards/forwards compatible is again much more difficult.

You do not need to stop an application first before upgrading it.

Maybe I am misunderstanding what you’re trying to accomplish?

To do hotcode reloading, you actually need to have the dependencies written for that, and you need to provide release upgrade scripts, which describe which modules in which application needs to get replaced.

There are probably more low level tools that could do hot reloading without releases, though it still requires that the applications are built with hot code upgrades in mind and that their GenServers or whatever keeps the state is able to convert old state to new state.

I think I missed in my questions!!
When I use Application.stop :mishka_developer_tools it shows me:

00:14:26.602 [notice] Application mishka_developer_tools exited: :stopped

I think, all the state of this app after I run this function is gone. Without stop, I can not update a full project, not a module!!

I think I need to solve this problem at first, how to update a dependency which is in Application.loaded_applications, actually now I first delete it and load again

Do you suggestion?

I am no families enough with Erlang, but I found this post:
https://www.erlang.org/doc/design_principles/release_handling.html#release-upgrade-file

So could not test it

By the way, I found this article in the following comment: https://stackoverflow.com/questions/36196148/elixir-how-can-i-leverage-release-handler

And I have read the release section of “Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems” book.

I am not sure, but I think using release for installing multi version of dep is not going to work perfectly in elixir, or I could not use it!!

Hot Code Upgrades mix release — Mix v1.19.5

Erlang and Elixir are sometimes known for the capability of upgrading a node that is running in production without shutting down that node. However, this feature is not supported out of the box by Elixir releases.