InitializableAdminUpgradeabilityProxy in solc 0.7?

I am upgrading an environment containing proxies from solc 0.5.x to 0.7.x. Previously, the proxy contracts were created using InitializableAdminUpgradeabilityProxy from "@openzeppelin/upgrades": "2.7.2", however it appears that the library has been deprecated in favour of native hardhat integration.

:computer: Environment

    "@openzeppelin/contracts": "3.3.0",
    "@openzeppelin/upgrades": "2.7.2",
    "hardhat": "^2.0.3",

:memo:Details

While I can see the benefit long term from creating better DX during testing and development, this limits my ability to do manual deployments for single contract deployments, or contracts that have nested dependencies (i.e. the initialize fn of one relies on the proxy address of another). Also It would be great for me to retain backwards compatibility in the codebase to ensure that subsequent upgrades on existing contracts go smoothly.

Are there any branches with 0.7.x ports of the contracts in question?

1 Like

Hi @alsco77,

As an aside, you should be able to do nested deployments using the Upgrades Plugins for Truffle or Hardhat.

The proxy contracts that were in OpenZeppelin Upgrades library have been added to OpenZeppelin Contracts. See: Building for interoperability: why we’re focusing on Upgrades Plugins

There is a Solidity 0.7 tagged release of OpenZeppelin Contracts.

Please note, the Upgrades Plugins don’t currently use the proxy contracts from OpenZeppelin Contracts. They use a variant (prior to migration to OpenZeppelin Contracts) that is for Solidity 0.6.

@alsco77 The “initializable” variant of the proxies was not migrated to OpenZeppelin Contracts, only the proxies that have a constructor.

Do you need the initializable variant? Please share more about your use case so we can figure out the best suggestion for you.

1 Like

@frangio @abcoathup Hey guys! Thanks for getting back to me :slight_smile:

Hmm. I don’t think its a necessity for me anymore… I was hoping to maintain backwards compatibility in the codebase itself, however since we aren’t re-deploying the proxy contracts, it shouldn’t affect the existing contract storage layout/functionality (although it’s always nice to test with the real thing).

Thanks for the info - will ping back here with more specifics if my current plan doesn’t work out

2 Likes