Keeping alignment with API development

[smk762]

Recently we ended up in a position where the master branch of the coins repo contained information which breaks the functionality of some methods in the current API release version. To avoid repeating this problem, the following suggestions have been made

• master branch should at all times be compatible with the latest API release binaries (mm2.1 branch)
• dev branch will be created, and should at all times be compatible with the API dev branch
• Additional branches can be created with the same branch name used in API repo for specific feature testing, before merging into dev and eventually master.
• Upon release of a new version of the API, a git tag with the same version number / short hash as the API release will be created to offer a static fallback reference. new coin additions for existing protocols can be added to master (and should still function with the API release), with the option to add incremental tags if required or on a schedule once a week/month).
• GUIs which reference the coin_config.json generated by this repo's CI should use tags / short hashes to source the data, so we can avoid builds failing due to potentially introduced errors.

Please add any more suggestions or pros/cons below. cc: @yurii-khi @artemii235 @ozkanonur @tonymorony @cipig

[cipig]

The ideal solution would be if the GUI would fetch coin_config.json from this repo on every start, so people don't have to wait for a new release just to have some coins added.

[smk762]

The ideal solution would be if the GUI would fetch coin_config.json from this repo on every start, so people don't have to wait for a new release just to have some coins added.

For desktop I've considered this - run "reset assets" or maybe have button to update assets would grab the latest pinned commit. Add a little "new coins listed" message above the button in settings so user knows and can update. I'll fold this in when I revive the "keep active on restart" PR for 0.5.8.