Francisco Giordano

This is still an issue but I don't believe it would be right to encode the 63/64ths rule in the Solidity code. I think this is just a limitation that...

There was a change to how Solidity treats "overrides" from interfaces in 0.8.8 that might make this change non-breaking from that version on. We should try with 0.8.0 and see...

We are now doing code generation but retain the "type erasure" approach due to backwards compatibility of the storage layout (arguably a limitation of our Upgrades Plugins). https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3429#issuecomment-1194551666

2. The recommendation for the upper limit of 5000 came from https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2355#issuecomment-1200144796. I think I feel ok with making that customizable through an overrideable function. Even if OpenSea caps it...

Changed the file naming convention as suggested. Still only applies to contracts under `contracts/mocks/` because we want to see the warning for the production contracts.

In this PR you kept the getters but removed the modifiers. The issue https://github.com/OpenZeppelin/openzeppelin-contracts/issues/3599 is asking to remove the getters entirely. This change needs to go to the `next-v5.0` branch,...

Inspected the above postinstall scripts and they're safe.

I would like us to review the "mock" name and switch to a new one. Maybe we can just rename everything to `Test` instead of `Mock`. See https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1320

Thanks @kargakis. This is a good suggestion. There are a couple of caveats though. `@deprecated` is not valid NatSpec so we would have to use `@custom:deprecated`. Solidity 0.8.0 does not...

I'm not sure I see the distinction. `/// @custom:oz-upgrades-...` is NatSpec! It is a breaking change because if we add a comment like that to a private variable Solidity 0.8.0...