Consider version tracking via VaultFactory

[pajicf]

As mentioned in the call on Wednesday, keeping onchain track of Vault releases via VaultFactory might prove to be useful.

The problem

Currently the VaultFactory.sol contract keeps track only of the current to be used Vault implementation that's changeable via new incoming setVaultImplementation() funciton.

Implementation in current condition:

• Forces users to use only the latest version
• Will be allowing migration from any version to latest one which might not be possible in some more complex migration scenarios.

The proposal

Introduce a versioning system which allows new implementations to be added but old ones are still tracked. Introduce a whitelisting system via which an implementation can be flagged as unsecure and new vault creations using that implementation would fail but still be allowed to migrate from it to new version. Force upgrades to happen from latest compatible version or at very least only from the previous versions.

This system would also allow transparent and reliable onchain way of tracking releases without having to be constantly active on development updates but just react when

The changes

New release function
We'd introduce new function called newRelease(address _vaultImplementation) which would store the new address in a mapping (uint releaseNumber => address vaultImplementation) public releases or it can be a struct instead of address containing richer data like isSecureRelease or similar.
It a event NewRelease(address implementation, uint releaseNumber)

Modifications to createVault() function
The createVault function would accept a new param uint releaseNumber which is optional. If undefined, the factory simply deploys the latest release, if defined we check if its been flagged as unsecure to revert or deploy otherwise.

Modification to migrateVault() function
Check if we're migrating from previous release to new one, otherwise revert. This makes it possible to be sure that migrations happen without bugs as we are sure to test migration from v1 to v2, or v2 to v3, instead of v1 to v6 for example which may have some breaking changes not able to be handled in the migration process.
If we do it like that, we'd have to consider either allowing deployment of insecure vault temporarily while migrating or provide a "force" migration flag as a function parameter.

Resources

The proposal is not isolated idea, but brought from experience on how Yearn managed Vault versioning since they were non upgradable contracts.
You can find implementation example on which these ideas are based on here: Registry.vy