What's the best way to keep up to date my solidity and OZ version?

Support Contracts
, ,
1

Hi there, I'm working with a big smart contract structure, there are around 20 contracts deployed and interoperating. This platform is constantly getting updates and tweaks, we use Upgradeable contracts and most of the OpenZeppelin features and facilities.
However, after a while we noticed how far behind we were on the Solidity versions and also at the same time on the OpenZeppelin versions. We are now facing a big migration that involves a couple of versions of Solidity and OpenZeppelin. We would like to not face this again in the future and have been looking for some answers on how to deal with this regularly and cheaply instead of once a year but costly.

So here are the main questions that arise:

  • How do you decide what version is worth upgrading? Since there is a cost related to the update, this decision is not trivially "all versions are worth", right?
  • We have contracts that are the base of our platform which are inherited all over the place, for example the OpenZeppelin standard "Ownable". That contract has a strict version of solidity meaning that if we update that contract, we will need to update every dependant, right? If not, how can we reproduce production in other environments?
  • What about the AdminUpgradeabilityProxys? They cannot be redeployed with a newer version, right? Those will stay on the oldest version that we have. Is that an issue? Were there enhancements in AdminUpgradeabilityProxy since 2019?
2

My suggestion would be to subscribe to the releases in the OpenZeppelin Contracts repository and read the release notes as they come out, to decide whether that release is worth updating to. You will sometimes find optimizations that may be relevant to your contract, or new features that you'll realize you could use.

Whenever there is a new major release, you should schedule some time to update to it as soon as possible.

That said, it is not simple, and sometimes not possible, to upgrade contracts from one major version to the next. The reason is that we do not keep storage layout compatibility across major releases.

You can also subscribe to Solidity releases and follow a similar procedure to decide whether to update in the spot or not.

What do you mean by this question?

Indeed, you can't redeploy it. Besides, if you're using our Upgrades plugins to deploy, the proxy code is controlled by the plugin. If we update it, you will receive that update.

3

Hey there @frangio, thanks for the reply.

My point was: We have a base of contracts that we deploy every time for different clients. For the new clients we will deploy everything with the latest versions. But for old clients we will be forced to keep some old versions of the contracts, specially if the dependencies involved are OZ contracts that reordered/changes the storage sturcture.
So, how could we reproduce a production environment which have some contracts in solidity 0.5, some other contracts in solidity 0.8 and some proxies with even older versions of solidity? Can we create a local environment that holds all this? If so, would it require to deploy everything in the oldest version and then upgraded?

That's pretty bad :S can't you keep a gap and use that gap? Why do you decide to do that?

4

The gap is not necessarily enough. There are some changes that are simply incompatible when upgrading.

At some point we need to break backwards compatibility, otherwise we're not able to move the project forward. :pray:

Security fixes will always be backported to previous versions.

1 Like
5

I think you should be able to get a local environment with both Solidity 0.5 and 0.8 contracts. It might be a little complicated, you may need to install multiple versions of dependencies, etc. But I think it can be done.