Openzeppelin-contracts: Support for Solidity 0.7.0

Created on 29 Jul 2020  ·  14Comments  ·  Source: OpenZeppelin/openzeppelin-contracts

🧐 Motivation
I know solc 0.7.0 was only released yesterday however logging it here for consideration.

📝 Details
Upgrade contracts to solidity 0.7.0 which overall doesn't have as many breaking changes as 0.6.0 so shouldn't be that invasive. Mostly it is maintenance updates and switching certain compiler warnings to errors.

Most helpful comment

Support for Solidity 0.7 has been published in a specially tagged release @openzeppelin/[email protected].

You can install with npm install @openzeppelin/[email protected].

Other than the support for Solidity 0.7 this release corresponds to OpenZeppelin Contracts 3.1.0.

All 14 comments

Reposting here my comment in #2319:

We still haven't figured out how we're going to fit support for Solidity 0.7 in our versioning scheme, since the pragma bump is a breaking change. We may want to continue providing support and new features for Solidity 0.6 in parallel to supporting 0.7. So I'm merging #2319 to a new branch while we figure that out, and it also serves to wait until the linter and our docs generator are updated for 0.7.

Hmm... that means we can try getting our hands dirty with the above branch then?

Just a note that due to npm not supporting installation from a subfolder (in this case /contracts for the @openzeppelin/contracts package what's the best way to plug this in without changing the import declarations in our contracts? npm install https://github.com/OpenZeppelin/openzeppelin-contracts.git#solc-0.7 --save only updates the openzeppelin-solidity package. Only way I see right now is to publish own package, e.g. @openzeppelin-argent/contracts and switch imports. Can you think of a better way?

We are going to publish a tagged version on npm. Will try to do this as soon as possible.

Support for Solidity 0.7 has been published in a specially tagged release @openzeppelin/[email protected].

You can install with npm install @openzeppelin/[email protected].

Other than the support for Solidity 0.7 this release corresponds to OpenZeppelin Contracts 3.1.0.

tested the 7.0 branch and works fine! https://rinkeby.etherscan.io/address/0x25b64b8b410c82636f31e89f012a48b7d1a2b017

any plans for solidity 7.1?

ui Version 0.7.2 solidity is released

Hi @arpu,

You should be able to compile the Solidity 0.7 version of OpenZeppelin Contracts with Solidity 0.7.x as the pragma specifies ^0.7.0.

Support for Solidity 0.7 has been published in a specially tagged release @openzeppelin/[email protected].

Thanks though please put it into master

Seeing that https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2319 already got merged: What's blocking this from being released to npm as latest ?

@chapati23 What's blocking it is the fact that it's a breaking change for current users, and that we believe the majority are still on 0.6.

thanks for the explanation @frangio

rephrasing the question in that light: what speaks against releasing it as v4.x?

Good question. Bumping the major version would signal that there are "meaningful" breaking changes (name changes, semantic changes)... and that wouldn't be the case.

We haven't been able to come up with a good solution for this. So in the meantime we're publishing on npm with the tag solc-0.7, and this seems to be working reasonably well for users. There's downsides to it though, so we're still considering how to move forward.

Let me know what you think would be the best solution.

Yeah, it’s a bit tricky because your semver partly depends on an external dependency. I would argue that solidity 0.7 hat breaking changes, therefore it warrants a major version upgrade.

I think generally in the JavaScript space users expect npm install <package> to install the latest stable version of the package.

At some point it needs a decision. Solc 0.8 is already in preview, then it becomes even more confusing 🤔

On 4. Nov 2020, at 23:55, Francisco Giordano notifications@github.com wrote:


Good question. Bumping the major version would signal that there are "meaningful" breaking changes (name changes, semantic changes)... and that wouldn't be the case.

We haven't been able to come up with a good solution for this. So in the meantime we're publishing on npm with the tag solc-0.7, and this seems to be working reasonably well for users. There's downsides to it though, so we're still considering how to move forward.

Let me know what you think would be the best solution.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Flash-Git picture Flash-Git  ·  3Comments

spalladino picture spalladino  ·  4Comments

shyheim103 picture shyheim103  ·  4Comments

LogvinovLeon picture LogvinovLeon  ·  4Comments

mswezey23 picture mswezey23  ·  3Comments