Relx Upgrades

[Tristan Sloughter]

I'm using this code base to test relx upgrades: https://github.com/tsloughter/elevators

 

If you look in the Makefile you see the crap that has to be done to do an ugprade. There are two main issues I feel with using relx for this. First one is the need to do:

 

cp -R rel1/elevators/lib/elevators-1.0 rel2/elevators/lib

 

This is because while running, @./relx -o rel2/elevators -c rel2/relx.config -l rel1 relup, relx is able to discover the rel1 release to do the upgrade based on it is not able to find elevators-1.0 in the lib directory for rel1. This because of the following code in rlx_prv_assembler:

 

Options = [{outdir, OutputDir},

{path, get_code_paths(Release, OutputDir) ++

get_code_paths(UpFrom, OutputDir)},

silent],

 

The path set in the options is based on the OutputDir for both the new release and the old release. So it does not look in rel1/elevators/lib/.

 

Question is, should it attempt to find the rel1/elevators/lib or should elevators-1.0 required to be in the new releases lib directory (one way or another)?

 

Next, running relx relup doesn't only build the relup, it also builds the release. It should be able to run simply on releases, right? If it is able to be run on already created releases it allows some more leeway on paths that conflict depending on the use. An example being having no version number for the app in rel2/relx.config, if the release is built without that 1.1 version number on the elevators app and without "-l rel1" it will create a release with version 1.1. But without the version number in relx.config and with '-l rel1' as an argument it will find elevators-1.0 and use that, so mucking up the new release and making the upgrade impossible to make.

 

Thoughts?

 

--

Tristan Sloughter

tristan....@gmail.com