Installing patches

[vasu-dasari]

I am thinking of a use case where user would like to do development on one system and test the same on a different system. To be able to do that, he/she can build a release package file and install it on the target system and use it. Once deployed, say an erlang file has to change and to deploy that change we have two choices:

1. Create a new patch release with a new software version so that software can be deployed on the target system with install_upgrade.escript.
2. If we have some sort of hot-patch kind of option built into install_upgrade.escript, that can be used to just patch those files, it can be used to patch running system.

I think 2nd option would be good so that not every project using relx needs to write their own version of hot-patch escript. If this option were to be implemented it could look something like this.

bin/<release_name> hotpatch <list of files>

Let me know what you think.

[lrascao]

In your use case is there something preventing from using release upgrades to get the job done?

[vasu-dasari]

There is nothing preventing me from using release upgrades via option 1, identified earlier, just that I need to build the entire package and ship it to the target system, and unpack over there and upgrade. I would be able to save some time by just shipping beam files as patches.

I have code which does the option 2. I can do a pull request and you can see if it makes sense

[lrascao]

I've wrote a rebar3 plugin that aims to make option 1 simpler to the point where it could be automated, could you please take a look at it? If it fits your use case it would be a simpler solution that adding new functionality to relx

[vasu-dasari]

I have been using the rebar3 appup plugin you wrote for application upgrades. Thanks for the plugin. It works pretty well when I am doing release upgrade.

I could have 100 files in a project. But only 2 files might have changed. And I am still in development mode. I would like to update just these 2 beam files. In this scenario, hot-patch could be useful.

[lrascao]

The thing is the plugin does exactly this, it will detect the changes on those 2 beam files and generate a tarball with the change, the tarball can then be deployed (using whatever method you were planning with the hotpatch) and then the upgrade can be applied, all of this could be done automatically (if you so desire)

A hot patch functionality while developing is most useful (IMO) when you don't have to deploy the resulting beam files to some remote machine, the rebar3_auto plugin might be a possible alternative for this.

I really would rather not add duplicated functionality to relx, the patch you propose on #630 is a smaller version of release_handler which is proven and well tested