-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Etherscan-visible versioning to pools #2026
Comments
This was referenced Nov 22, 2022
#2032 added this for AaveLinear - we'll likely want to have this in |
This was referenced Nov 30, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a versioning system in the /deployments package and readme's that labels each deployment with a date, includes the complete build info, and often indicates a version in the name (e.g., gauge-adder-v2). Of course, none of this is known by Etherscan, so finding out which version a pool is could involve checking all the factories to find which one deployed it, then noting the date the factory was deployed, and looking it up in the repo docs, which is all manual and fairly cumbersome.
We could change the name of the contract itself, which would be visible in Etherscan - but we don't generally want to change the names of the contracts unless it is truly different (e.g., StablePool -> ComposableStablePool). If we're just fixing a bug or updating a dependency (e.g., Aave v2 to v3), the name should stay the same.
We could also have an external contract registry with metadata, including this information - and we may well do this at some point - but that's too heavyweight for now.
So the consensus solution is to add a
version
method to all pools that returns a string. Alternatively, if we want an easily machine-readable numeric value (vs parsing it out of a string), we could add aversionNumber
: 1,2,3,4,... and aversionName
, which might be a string identifying the task id (e.g., '20221111-authorizer-adaptor-entrypoint'). Then it would be trivial to find the correct deployment from EtherscanThe text was updated successfully, but these errors were encountered: