generated appup order

[tothlac]

Hi

This is not a bug, but a possible feature request.

We have around 60 erlang repos. All of them use appup plugin by either generating appup from appup.src calling appup compile, or it just calls appup generate if there is no appup.src.

We have an other plugin which does a lot of checks on our erlang projects. For example we have a check (let's name it upgrade_order_validation) which checks the following:

• if modA calls modB, but modB does not call modA, then our logic is that modB must be upgraded first, then modA.

During a downgrade it is the opposite: modA should be downgraded first. What is the reason?

If all api functions of a module are always backward compatible, so you never delete an existing exported function, but of course you can add a new modB:new/0, then if you upgrade modA first, there will be a small chance that modB is not upgraded yet, so calls to this added function will fail.

On the other hand if modB is upgraded first then the new function will already exist by the time modA is upgraded so it can call the new function. With a similar logic you can easily see during a downgrade you have to downgrade modA first since if you downgrade modB first, modA will still call the already purged function. If you don't follow this logic there will be failing requests during an upgrade.

Using xref we already have the entire calltree in memory, so what we do is that we reorder the generated appup file so it will follow our logic.

The question is whether you would be interested in moving this feature into the appup plugin?

[lrascao]

Hi,
The appup plugin also tries to do this (also using xref), but it's maybe lacking in some aspect since you felt the need to re-order the generated appup. all improvements are greatly appreciated so it would be great to merge the two approaches!

[tothlac]

Thanks for the quick reply! I will let you know when I will be able to merge it into the plugin.

[lrascao]

cool, to start you off, you can take a look at rebar3_appup_generate:module_dependencies/1 and see how it differs from your approach, that's where the plugin is trying to determine dependencies between modules