how should upgrades work?

[goastler]

No description provided.

[goastler]

We need to think about how upgrades will work, specifically regarding:

• providers
• contract (proxy and captcha)
• bundle
• client-server
  and how these will work together with each other.

There's loads of ways we can go with this, so please dump any + all ideas here with any pros/cons you can think of, then we can compare them

[goastler]

"Fixed version" is doing a release-per-version system, i.e. upgrade all components in one go. So this would be a new contract, new provider version, new bundle and new client-server package

pros:

• simple
• creates a good dividing line between versions, no inter-version support needed (and thus no bugs from old-new version)
• allows providers who do not upgrade to be left active in an old contract where no traffic is being routed
  cons:
• extra work, have to do a release for all 4 packages when as little as 1 has changed
• frequent contract releases creates migration woes
• frequent provider releases will be a pain for providers as they'll have more maintenance time doing all these upgrades
• likewise with dapp operators using the client-server package

[goastler]

Adhoc version, i.e. upgrade as required when packages change
pros:

• simple
• most minimal upgrade process, only the package that has changed needs upgrading
  cons:
• no division between upgrades, maximum need for inter-version communication which becomes factorially more difficult over time (i.e. would generate loads of legacy version communication, e.g. v1 talking to v2, v1 talking to v3, ... v5 talking to v8, etc)
• most likelihood of bugs from inter-version usage

[goastler]

Latest version, i.e. bar anyone not using the latest version
pros:

• simple
• keeps everything up to date, no need to support legacy so less dev overhead
• no need for inter-version communication
  cons:
• upon release, everyone would be barred as they haven't updated yet. This would leave the network with no providers

[goastler]

Latest biversion, i.e. bar anyone not using the latest 2 versions
pros:

• all of the pros from the latest version strategy
• allows a period where the penultimate release is still supported so the network does not run out of provider upon release of a new version of provider
  cons:
• extra dev overhead of making the last two versions work together

[goastler]

All versions, i.e. support all versions of every package forever
pros:

• forever support, no need for anyone to spend any time upgrading ever, so well suited to the set-it-and-forget-it people
  cons:
• massive dev overhead in supporting all legacy versions
• exponentially more overhead as releases accumulate

[goastler]

Latest migration versioning. Same as the latest versioning strategy, except we include a migration system to automatically migrate people to the latest version
pros:

• auto migration means no need for manual intervention, so no worry about old versions being active in the wild
  cons:
• if auto migration breaks, manual intervention required (unlikely / just as likely as things breaking during manual migration)
  cons:
• extra dev overhead to build the migration script per version bump, however this is much less than supporting inter-version communication

[goastler]

I'm in favour of the latest migration versioning strategy thus far. I think it is the most elegant solution with least dev overhead and least pain for clients