# Which version of OpenZeppelin Contracts should be used for upgradeable contracts? **URL:** \ **Category:** Upgrades\ **Created:** [November 4, 2020, 5:54pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410 "2020-11-04T17:54:42Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![elmariachi111](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/elmariachi111/32/17885_2.png) [@elmariachi111](https://forum.openzeppelin.com/u/elmariachi111)\ **Post date:** [November 4, 2020, 5:54pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/1 "2020-11-04T17:54:42Z")
I’m using upgradeable contracts for quite some time and just stumbled upon your CLI’s deprecation warning. Bold choice but I’d say it’s a step in the right direction. What still confuses me is which package to use to deploy upgradeable contracts (using the new truffle upgradeProxy features) -\> are we still supposed to use the premade `@openzeppelin/contracts-ethereum-package` contracts that contain e.g. the `ERC20PresetMinterPauser **UpgradeSafe** ` presets? Or would you recommend to simply use the non upgradeable contracts (containing constuctors) from `@openzeppelin/contracts` and manually extend them to implement the `Initializable` base that now is available on `@openzeppelin/contracts/proxy/Initializable.sol` (the [latest tutorial on upgradeable contracts](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) is actually using it but doesn’t say a word on how to proceed with the “old” UpgradeSafe presets. Its `Box` example is hard too compare with the preset erc20 token contracts…) This is quite confusing to say the least 😉 But hey, thanks for making all that so much simpler and safe! - even though it’s hard to stay synced with all these changes… _Moved from [The Future of contracts-ethereum-package](https://forum.openzeppelin.com/t/the-future-of-contracts-ethereum-package/3642)_ ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [November 5, 2020, 3:58am UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/2 "2020-11-05T03:58:54Z")
Hi @elmariachi111, I am sorry that it is confusing. When creating upgradeable contracts it is recommended to deploy using OpenZeppelin Upgrades Plugins (documentation: [https://docs.openzeppelin.com/upgrades-plugins/1.x/](https://docs.openzeppelin.com/upgrades-plugins/1.x/)). If you want to use/extend OpenZeppelin Contracts then you should use the Upgrade Safe fork which is currently OpenZeppelin Contracts Ethereum Package. (The plan is to change the name to make it less confusing: [The Future of contracts-ethereum-package](https://forum.openzeppelin.com/t/the-future-of-contracts-ethereum-package/3642)). There is an open issue to improve the documentation around the Upgrade Safe version of OpenZeppelin Contracts. ---
**Author:** ![frangio](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/frangio/32/15251_2.png) [@frangio](https://forum.openzeppelin.com/u/frangio)\ **Post date:** [November 5, 2020, 2:38pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/3 "2020-11-05T14:38:30Z")
Thanks for the feedback @elmariachi111! > [@elmariachi111](#): > > This is quite confusing to say the least 😉 But hey, thanks for making all that so much simpler and safe! - even though it’s hard to stay synced with all these changes… We know, and we're actively working on making it simpler, less confusing, and more documented. I've been working for the past few weeks on the plan outlined in [The Future of contracts-ethereum-package](https://forum.openzeppelin.com/t/the-future-of-contracts-ethereum-package/3642) and the work is almost complete. I think I can safely say we will be releasing it next week, along with some initial documentation. We'll make sure that the new package is mentioned in the relevant places and well explained. * * * As for your questions: > [@elmariachi111](#): > > are we still supposed to use the premade `@openzeppelin/contracts-ethereum-package` contracts that contain e.g. the `ERC20PresetMinterPauser **UpgradeSafe** ` presets? Yes, although note that you don't need to use the presets, you can use any contract from the package, as indicated by the "UpgradeSafe" suffix they are all safe to use with upgradeable proxies. > [@elmariachi111](#): > > Or would you recommend to simply use the non upgradeable contracts (containing constuctors) from `@openzeppelin/contracts` and manually extend them to implement the `Initializable` This would not work: `@openzeppelin/contracts` has constructors, and it's not possible to remove the constructors through inheritance by just adding `Initializable`. This is why there are two packages: one of them has constructors, the other doesn't (along with a few other necessary changes). ---
**Author:** ![elmariachi111](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/elmariachi111/32/17885_2.png) [@elmariachi111](https://forum.openzeppelin.com/u/elmariachi111)\ **Post date:** [November 5, 2020, 4:38pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/4 "2020-11-05T16:38:15Z")
yeah, that clears the skies a little 🙂 Awesome, thank you! After I posted that question here yesterday I tried to “migrate” a project from oz/cli to your new upgrade plugins, trying truffle first and buidler second. I must really say, that from a DX/convenience (deploy -\> upgrade -\> done) point of view we’re _really_ losing something here ([here’s my commit history](https://github.com/cod1ng-earth/ledger-academy/commits/stefan/oz-truffle) if you feel truly bored but I definitely don’t expect anyone to dig through it). At the moment: - truffle is ok. I mean, writing migrations in a meaningful way can be confusing (especially when you’re supposed to call one migration several times because it’s just upgrading a changed contract with new code - did you notice, that their migrate command takes a `--to` flag and a `--f` (sic!) flag? - next, truffle puts the deployed contract addresses right into their build output - when working with oz, I simply gitignored the `build` folder and recreated it on each developers’ local machine - the live deployment addresses stayed committed in the .openzeppelin folder. When collaborating with several people each build / deploy on a developer machine would overwrite the built artifact file, removing the deployed artifacts for the next developer. Here’s an old Stackoverflow thread `https://ethereum.stackexchange.com/questions/24296/what-is-a-standard-gitignore-for-truffle#comment31291_24300` that actually came to the same conclusion;) - When I used truffle to “migrate” a simple upgrade safe ERC20 to Görli using Infura, it ran the dryrun first and then arbitrarily crashed while deploying the “real” thing. That felt way more unstable than an oz deploy --network goerli. So I tried buidler. Well, hardhat that is (now). Only that your plugin docs `https://docs.openzeppelin.com/upgrades-plugins/1.x/buidler-upgrades#install` aren’t compatible to hardhat’s recent [rewrite of their deplyoment tools](https://docs.openzeppelin.com/upgrades-plugins/1.x/buidler-upgrades#install). So at 2am I switched back to buidler, nearly the same and it works with your new plugins, great 🙂 But wait, there is no thing like an “oz deploy” there (and that super massive 3rd party “deploy” plugin `https://hardhat.org/plugins/hardhat-deploy.html` is not “officially unsupported”) but I must write deploy scripts on my own? Well, that’s certainly powerful, but boy I’m going to miss `oz deploy` for sure (and so is my team) ☹ ---
**Author:** ![frangio](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/frangio/32/15251_2.png) [@frangio](https://forum.openzeppelin.com/u/frangio)\ **Post date:** [November 5, 2020, 7:14pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/5 "2020-11-05T19:14:05Z")
> [@elmariachi111](#): > > I’m going to miss `oz deploy` for sure (and so is my team) I feel you. Unfortunately there was a _lot_ more to the CLI than `oz deploy`, and it was not sustainable for us to keep working on it. We decided to prioritize building security features over pure developer experience features in the form of the Upgrades plugins. I would expect more deployment solutions to emerge for Hardhat. As for Hardhat support in the Upgrades plugins: we're working on this and it will likely be released in a few days. If you have any other feedback about the plugins feel free to reach out or open issues in the repository. ---
**Author:** ![frangio](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/frangio/32/15251_2.png) [@frangio](https://forum.openzeppelin.com/u/frangio)\ **Post date:** [November 12, 2020, 10:58pm UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/6 "2020-11-12T22:58:53Z")
@elmariachi111 Check out our latest release for the upgradeable version of OpenZeppelin Contracts. > [@First release of OpenZeppelin Contracts Upgradeable](https://forum.openzeppelin.com/t/first-release-of-openzeppelin-contracts-upgradeable/4548): > > In [The Future of contracts-ethereum-package](https://forum.openzeppelin.com/t/the-future-of-contracts-ethereum-package/3642) we described our plans to improve the experience of using upgradeability together with OpenZeppelin Contracts, our secure library of smart contracts. Today we’re finally releasing the new package that is the result of this work, meant to replace the existing @openzeppelin/contracts-ethereum-package. On the surface, this release will not seem like a big deal. While the package name has changed, and contract names have slightly changed as well… Also some improved documentation! > **[Using with Upgrades - OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/5.x/upgradeable)** Thank you for the feedback so far! 🙏 I would love to hear what you think of the new release and docs. ---
**Author:** ![elmariachi111](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/elmariachi111/32/17885_2.png) [@elmariachi111](https://forum.openzeppelin.com/u/elmariachi111)\ **Post date:** [November 18, 2020, 10:52am UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/8 "2020-11-18T10:52:31Z")
Hey @frangio . Imo the docs are concise and good to go - haven’t tested with hardhat again but I assume it’s simply working 🙂 I’ve [migrated our codebase to use the plugin](https://github.com/cod1ng-earth/ledger-academy/tree/devel/contracts/migrations) and after some struggles with deploying on goerli testnet using truffle (it’s definitely worth telling truffle to use infuras websocket endpoints) I was able to upgrade contracts. I’m still struggling with the big question what must go into source control here - I committed the new .openzeppelin folder that contains the logic contract addresses but it doesn’t point us to the proxy contract which is the entrypoint for our app to call. I’m hesitating to commit the truffle build output instead since it also contains all information of my local dev chain and that’s absolutely nothing you’d like to put under source control since it’s unique to each developer 🙄 BTW: the app built by the repo is deployed on ipfs here: [https://ledger-workshop.eth.link/](https://ledger-workshop.eth.link/) ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [November 19, 2020, 2:53am UTC](https://forum.openzeppelin.com/t/which-version-of-openzeppelin-contracts-should-be-used-for-upgradeable-contracts/4410/9 "2020-11-19T02:53:09Z")
Hi @elmariachi111, The advice for version control is as follows: > **[Network Files - OpenZeppelin Docs](https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files#configuration-files-in-version-control)** Though I appreciate that there is still an issue about the proxy addresses and the best way to handle these.