I want to access past dApp versions on hosted instance to be able to close/settle channels

[andrevmatos]

User Story

Now that we have figured out saving artifacts for built versions and deploying and serving built dApp from any relative paths, it should be feasible to have each tagged/released version served from a different path on the deployed instance (e.g. https://lightclient.raiden.network/v0.9.0/).

Also have a small screen on Accounts before connecting to list and direct (with reload) to these old versions. On old-versions which wouldn't have this screen, the user can simply access / or /staging manually, to access stable and development versions, respectively. This screen should also list the registry address associated with each version, which identify the different states per channel currently stored on localStorage.

Optionally, a badge to show if there's a state in storage for a given version, and even a counter of channels last seen as open on each version/state could also better inform the user if they need to access these older versions to close and settle their channels.

The serve_pr container/script/tool can also be adapted to fetch these released versions and serve them locally on the respective relative paths.

This would be specially helpful for mainnet (if we end up hosting an instance there), but also to clean on-chain states for past versions.

Acceptance criteria

• User can access older versions deployed in specific paths (after all, these are just static files of a client-only web app)
• User can see (at least on recent versions) a list of available older versions on Accounts page before connecting, with its respective TokenNetworkRegistry addresses, and access them.
• Optionally, the list above can also include visual indicators if there're stored states for the respective versions, and even open channels count.

Tasks

Why do this?

Provide a way for users to get back to older versions of the dApp if they find themselves migrating to a new version and for some reason wants/needs to use an older version.

[christianbrb]

@andrevmatos Don't we always migrate the state to the next version?

[andrevmatos]

We do, but the state is unique per blockchain+tokenNetwork+account, so they don't get upgraded/touched when new smartcontracts get deployed, allowing a past compatible version to use it. Besides this, with the #2044 , I plan to keep backup of the states upon migrations, so before-migration states can still be used with compatible instances.

[christianbrb]

Ok, make sense :)