Overview

Currently, EDS supports the ability to create source control and distributions, which are consumed by users via distributors. However, EDS lacks the functionality to upgrade instances from older versions to newer ones. The current method requires uninstalling the old instance and installing a new one.

To enhance the user and developer experience, a built-in workflow for upgradability should be developed. This workflow should define:

In order to increase UX for both users and developers, a built in workflow for upgradability should be elaborated. This workflow should define:

• Rules and interfaces needed to upgrade or downgrade an instance
• Data migration patterns in case version changes affect the instance data store

Design considerations

1. Version control systems must use distributions intended for upgradability

• There are no known methods to copy data store from one implementation to another reasonably. Changing application addresses for upgrades might negatively impact user experience.
• Distributions should be loosely coupled, allowing them to be unaware of version control use. Distributions may create upgradable contracts to change implementations seamlessly.

2. Repositories and Migration Instructions

• To maintain a loosely coupled architecture, repositories and distributions should remain within the developer's trust domain. Distributors should ensure version requirements and support user upgrades.
• Distributors may find it convenient to use developer-provided migration suggestions directly from source control and wrap them with their own parameters.

3. Installer Limitations

• The trust flow is from Distributor to Installer, meaning the Distributor must call the instance with upgrade instructions.

4. User Control Over Version Requirements

• Users must initiate the upgrade process to prevent distributors from breaking trust assumptions (e.g., viewing depreciation of the old version as a denial of service). Instances must call installers to verify user agreement on upgrades.
• An interface should be provided for installers to change distributors, bypassing potential denial of service.

5. Distributor Ownership of Migration Contract Design

• Distributors must own migration contract design even if newer releases fit into semantic versioning requirements. Distributors may choose to modify developer-provided migration instructions to fit their needs.
• Distributors must explicitly upload migration contracts and specify version requirements for current and requested upgrade versions.

Suggested Implementation

• Provide upgradable distribution abstract for developer convenience of creating packages intended for version control.
• Add migration data to the repository for each major release, containing calldata for new implementations for each source in the distribution.
• Users must call the Installer contract to request an upgrade with a specific version from the Distributor contract.
• Distributor contracts need a new interface specifying the migration contract address.
• Distributor contracts need a new interface for handling Installer calls to upgrade, which checks the instance ID, verifies instance version and requested new version, and passes the instance addresses with installer-supplied payload (optionally using Developers provided calldata from Respository) to the migration contract.
• Installers must have a hook to validate authorization by user call from distributor to instance contract.