improve(README): Add details about deployed contract versions

[nicholaspai]

We should move the deployed tag to whichever contract version we end up deploying

[pxrl]

By deployed do you mean a git tag that gets updated each time we make a new deployment? If so, does that work in the case that we add a new chain? Then we'd be marking deployed against the entire state of the repository, but there might have been some minor adjustments to other contracts that were not re-deployed afterwards.

[nicholaspai]

By deployed do you mean a git tag that gets updated each time we make a new deployment? If so, does that work in the case that we add a new chain? Then we'd be marking deployed against the entire state of the repository, but there might have been some minor adjustments to other contracts that were not re-deployed afterwards.

I think we should move up the deployed git tag whenever we want to signal that the latest code in contracts match deployed addresses. This unfortunately doesn't handle the case well where SpokePool implementations differ between chains...TBH I'm not sure yet how to handle that. We could maintain a mapping of chain ID --> git commit hash but this is better than what we currently have where one's best guess is that master matches deployed but that's not true pretty frequently

[pxrl]

By deployed do you mean a git tag that gets updated each time we make a new deployment? If so, does that work in the case that we add a new chain? Then we'd be marking deployed against the entire state of the repository, but there might have been some minor adjustments to other contracts that were not re-deployed afterwards.

I think we should move up the deployed git tag whenever we want to signal that the latest code in contracts match deployed addresses. This unfortunately doesn't handle the case well where SpokePool implementations differ between chains...TBH I'm not sure yet how to handle that. We could maintain a mapping of chain ID --> git commit hash but this is better than what we currently have where one's best guess is that master matches deployed but that's not true pretty frequently

How about having a tag for each contract that gets updated when it's (re)deployed? For example spokepool-arbitrum-deployed. It implies a little bit of management, but we don't deploy all that often.

[mrice32]

LGTM!

[nicholaspai]

By deployed do you mean a git tag that gets updated each time we make a new deployment? If so, does that work in the case that we add a new chain? Then we'd be marking deployed against the entire state of the repository, but there might have been some minor adjustments to other contracts that were not re-deployed afterwards.

I think we should move up the deployed git tag whenever we want to signal that the latest code in contracts match deployed addresses. This unfortunately doesn't handle the case well where SpokePool implementations differ between chains...TBH I'm not sure yet how to handle that. We could maintain a mapping of chain ID --> git commit hash but this is better than what we currently have where one's best guess is that master matches deployed but that's not true pretty frequently

How about having a tag for each contract that gets updated when it's (re)deployed? For example spokepool-arbitrum-deployed. It implies a little bit of management, but we don't deploy all that often.

So that means we'd need to maintain N different tags for N chains with SpokePools? You think that's worth it?