As we come close to finishing writing our smart contracts and test suite for our project using ZeppelinOS I just wanted to check what the recommended way of structuring our code and deployment/upgrade process.
From the tutorials and guides we have followed so far the suggestion has been to have only one code file per smart contract (eg, MyContract) which if it ever needs updating/fixing/upgrading is amended directly and then pushed and updated via the following commands:
npx zos push npx zos update
Although Circle/USDC used the Zeppelin upgradeability proxies (but not ZeppelinOS) they used a pattern whereby they created their initial contract version as ‘FiatTokenV1’ and then it looks like new versions of the contract which had bug fixes, etc would be ‘FiatTokenV2’, etc… This seems to be more structured but I am just wondering how that affects the upgrade process and commands now required as you may not be able to do exactly the same as before?
Are there any guides/tutorials out there which show how to use ZeppelinOS to upgrade contracts on one of the public networks (mainnet or testnet) using the V1, V2 structure?