Beta: Upgrade Policy

We are very close to releasing a beta already. One important thing about it is
how do we handle compatibliity.

The rule is that every new release should be compatible starting from 0.9.20 and further.

What does that exactly mean?

  1. User’s data. User should be able to successfully upgrade preserving all his/her data from 0.9.19 to any beta release.

  2. Messaging/Transactions. User should be able to successfully interact (make transactions, chat, etc) with users that have 0.9.20 or later release.


  1. Nice-to-have: Doomsday scenario. We need to be able to show a message to any user with any version with an upgrade notification in case we will absolutely have to break backward compatibility. This should not require any re-publishing of the app.
3 Likes

@goranjovic mentioned in today’s meeting both the need for the doomsday scenario, as well as tagging each message with a minimum-version info, so that older clients can tell if they will be able to correctly render a received message or not (the example was a wallet request message, which on older versions assumed ETH, but on new versions supports ERC20 tokens). In case they don’t support the message type, the older client can prompt the user to upgrade the app.

1 Like

Nice-to-have: Doomsday scenario. We need to be able to show a message to any user with any version with an upgrade notification in case we will absolutely have to break backward compatibility. This should not require any re-publishing of the app.

How about having a “Status” chatbot that we could trigger externally for a given version of the app. A user that opens the chatbot would see our message. Users would be also able to delete this chat.

But, having a (centralized) way to show messages to anyone may scary our users. I’m not sure if this approach is in line with our values.

1 Like