dApp - update to new version broken

[weilbith]

With the release of v2.0.0 also a new version of the dApp got build and published. The dApp its update strategy should now detect the new version number on the server and inform the user that he can update his local client. This feature is currently broken as there is an error in the code that fetches the version from the server. It validates if the received version number is in a valid format to ensure it can compare the version to the local one.

We have verified that if we reset the public dApp version to v1.0.0, "install" this version and then go back to v2.0.0 on the web-server, the dApp correctly detects the update and the user can update. With the now "installed" version v2.0.0 there is the warning message in the console about the version validation. Also the experiment to artificially increase the version number on the server to v2.0.1 proofs that the dApp does not inform the user about a possible update.

This is a very serious issue. Because this means every user which updates to v2.0.0 can never update again to any new release we do. Only if he gets support to use the developer tools of his web-browser. Therefore we have reset the official hosted version to v1.1.0 where updates still work properly. We now fix this issue and then release a patched version. The users will then update directly from v1.1.0 to v2.0.1.

This issue is a bit awkward. The related code has not been touched since 1 year. The error message points us to a an issue with a call to a 3rd party library which is doing the version validation. Though the error message is not very helpful despite that. Combining those two information, it seems like a library update has caused this issue. Which one is unclear. A first quick test with a NodeJS REPL was not helpful. Deeper investigations are necessary.

It is worth to mention that this is the probably only feature that has no end-to-end tests. We have unit tests for it, but they are still successful. The end-to-end test case has been validated as too complicated and expensive with no clear solution approach. Practical tests where always positive so far when the feature was touched (which was not the case here). With this experience and because the risk is very high, we should strongly consider to add such a test now.
The problem is also that this update functionality is only working in a production build.

Also note that this issue is so critical for this update because this update brings a new contract version. In result users can't access their "old" channels anymore if they have already updated.

[weilbith]

The broken version v2.0.0 was only live for ~2h. As our user-base is very small it is very unlikely that anyone did already update to the new version.
In case someone still did, we will use the old strategy to handle this issue and host the v1.1.0 where the update is still working under a sub-path. This will allows users which updated "too early" to still access their channels of the old contract version.