This looks very interesting, I will have a play. I would definitely like to see this kind of thing either move into OTP proper, or be based on supported/documented OTP features - e.g., if the OTP team made the extended API for systools/reltool official.<div>
<br></div><div>Oh and personally I would prefer <span style="color:rgb(51,51,51);font-size:13px;line-height:19px">updo:dry_run(details) or </span><span style="color:rgb(51,51,51);font-size:13px;line-height:19px">updo:dry_run(high | low) to </span><span style="color:rgb(51,51,51);font-size:13px;line-height:19px">updo:dry_run_low, but that's just a matter of taste. ;)</span></div>
<div><font color="#333333"><span style="line-height:19px"><br></span></font></div><div><font color="#333333"><span style="line-height:19px">Nice work.<br></span></font><div><br><div class="gmail_quote">On 4 February 2012 12:05, Per Melin <span dir="ltr"><<a href="mailto:per.melin@gmail.com">per.melin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OTP release management, if you need most of the benefits it offers, can undoubtedly be very useful.<br>
<br>
But I believe that most of us don't need most of those benefits most of the time, and that all the careful administration it requires can be a hindrance and even a source of errors. Especially if you are running your code in-house and do frequent incremental releases.<br>

<br>
Unfortunately the next best thing is to restart the node or simply reload the changed modules and hope for the best. I think there is room for something better than that.<br>
<br>
I've toyed with different solutions and the best I've come up with is an application that does this:<br>
<br>
1. Compare the loaded code with the beam files on disk to find modules that have been changed.<br>
2. Use xref to figure out any dependencies between the changed modules (who calls whom).<br>
3. Inspect the modules to separate supervisors, special processes like gen_server, and the rest.<br>
4. Generate a script with appup instructions, based on the previous steps.<br>
5. Use systools to compile this script to a lower level relup script.<br>
6. Ask release handler to execute the low level script.<br>
<br>
You can find the code here. It is only about 200 lines.<br>
<a href="https://github.com/permelin/updo" target="_blank">https://github.com/permelin/updo</a><br>
<br>
With this you don't get named releases or a bundled ERTS, but you do get the same code upgrade process as with a proper release; suspension of special processes, optional update of their states, updated child specs for supervisors, modules are reloaded in a logical order, etc. And it does not require you to keep app and appup files perfectly maintained or jump through any of the hoops otherwise associated with releases.<br>

<br>
There are however also some potential problems. At the top of my head:<br>
- To accomplish steps 5 and 6 I am calling functions in systools and release handler that are exported, but were most likely never intended to be used outside those applications.<br>
- xref will not always be able to find all cross-module calls, or do something about circular dependencies. Though I'm not sure it will do a worse job than a human manually writing appup instructions.<br>
<br>
Any other problems I've missed? Ideas? Questions? Wouldn't something like this be nice to have in OTP?<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>