If you're unfamiliar with "Contracts Ethereum Package", it's a variant of the popular OpenZeppelin Contracts but for upgradeable contracts. It ships a modified version of the regular contracts so that they support proxy upgradeability: by replacing constructors with initializer functions, delaying initialization of state variables, and ensuring storage layout compatibility across versions.
This post is the continuation of Planning the demise of OpenZeppelin Contracts' evil twin from November last year. In that post, @spalladino proposed two alternative plans for improving the user experience around using OpenZeppelin Contracts with upgradeable contracts by getting rid of Contracts Ethereum Package, affectionately referred to as Contracts' evil twin.
Plan A consisted in merging Contracts Ethereum Package into the "vanilla" OpenZeppelin Contracts, shipping both sets of contracts together. Plan B consisted in getting rid of the upgradeable variant altogether, and automating at "compile time" the necessary source code transformations needed on vanilla Contracts.
Plan B was the clear winner at the time and so we moved forward with building the so called Transpiler. We hadn't got to the point of integrating it into the OpenZeppelin CLI workflow by the time Contracts 3.0 was going to be released, so to make Contracts Ethereum Package easier for us we decided to repurpose the transpiler into a standalone tool we could use to build the upgradeable variant, which would continue to be shipped as the Ethereum Package.
Since then we've been focusing our efforts on building a better programmatic API for deploying and managing upgradeable contracts, which has now been released as the OpenZeppelin Upgrades plugins for Truffle and Buidler. Now that it's been released we're focusing again on the issue of improving the experience of using OpenZeppelin Contracts and upgradeability together.
While our end goal is still to provide an upgradeability transpiler for the end user, it's a significant effort and it will take us a while to get there. But there is nonetheless a number of improvements we can already make in the immediate future. We've decided to tackle the following two issues.
Confusing name. The name "ethereum package" turns out to be very generic, thus it has bad discoverability and it doesn't explain its purpose very well.
Release cadence. The Ethereum Package variant tends to have delayed and slower releases. This is due to a lot of manual work we still have to do for every release.
To tackle the first issue we've decided to use the "upgrade safe" terminology introduced in Contracts Ethereum Package 3.0 the "upgradeable" term, and release the package under a new name: @openzeppelin/contracts-upgradeable. We hope this does a better job of communicating the purpose and contents of the package.
Update
In the end, we went with "upgradeable" to avoid any potential confusion with Gnosis Safe. See the release announcement at First release of OpenZeppelin Contracts Upgradeable.
To improve release cadence we will be automating as much of the process as possible. First and foremost we have to improve the transpilation process so that it doesn't need manual intervention, and a big part of this is figuring out how to run the same test suite on the transpiled contracts. And then we want to put in place a continuous integration pipeline that will run this process on every commit to the vanilla Contracts repository, so if any issues come up we'll detect them as soon as possible. With this in place it should be simple to put out releases in parallel with vanilla Contracts.
Let us know if you have thoughts about these plans! Have you had any issues with Contracts Ethereum Package that I didn't mention? Is there any other improvement you would like to see?