github.com/OpenZeppelin/openzeppelin-sdk Roadmap for April - June 2020 frangio Last quarter we focused most of our work on the CLI. We introduced regular deploys in CLI 2.8, and developed the...

Full text reproduced below.

Last quarter we focused most of our work on the CLI. We introduced regular deploys in CLI 2.8, and developed the first version of the upgradeability transpiler.

For this quarter, rather than jumping on to the ambitious SDK 3.0 project, we’ve decided to make a deep dive into the building blocks of our upgradeability offering and mostly focus on the @openzeppelin/upgrades library. After some consideration we think there’s a lot of untapped potential in this library and we want to take some time and give it the attention it deserves.

Moving Proxies to Contracts

For a while we’ve wanted to move the actual Solidity source code for the proxies to our OpenZeppelin Contracts library. We’ve finally decided to make the move now. We expect the contracts to receive more continued maintenance and reviews once they’re under the Contracts umbrella. We may also push towards more proxy standards being included over there.

Redesigning the JavaScript Library

The library has existed since the beginning of this project as an alternative to the CLI, but the focus has mainly been on improving upgradeability as managed through the CLI. Thus, several issues in the library haven’t been tackled and the experience of using it is not as good as we’d want it to be. We now think the library has value in itself, so we want to make it better and easier to use, in particular designing a good API that is flexible and powerful at the same time.

We think this is an essential building block for upgradeability, and we hope these improvements allow upgrades to be integrated into tools other than our own CLI, and other use cases that we haven’t thought of ourselves.

Standalone Transpiler

The “upgradeability transpiler” is a Solidity preprocessor that converts a contract’s constructor into an initializer functions, moving all of the storage initialization into it and taking other necessary precautions when deploying contracts behind proxies. See our guide on Writing Upgradeable Contracts to learn more.

We continue betting that the transpiler will become the standard way to get contracts ready for upgradeability. Since we will improve the use of the OpenZeppelin Upgrades library on its own, we’ve also decided to make the transpiler available as a standalone program, so that both can be potentially used in combination independently of the CLI.