search

ewasm / design

Ewasm Design Overview and Specification
Apache License 2.0
1.02k stars 125 forks source link

EEI redesign process #108

Open chfast opened 6 years ago

chfast commented 6 years ago

This proposes the process of introducing changes in the EEI specification to move it from the revision 2 to the revision 3.

Each of the methods in EEI should be reviewed and discusses (with proposing alternative solutions) as an individual discussion threads. See examples:

When a consensus about the changes is reached, changes are applied to the document. In some cases we might want to reach out to https://ethresear.ch or https://ethereum-magicians.org.

In the end the revision 3 is published as a draft to be reviewed by broader audience.

In what form do you want to keep the documents? Do we want to keep the obsoleted revisions?

lrettig commented 6 years ago

Thanks @chfast. Why not do what EIP does? The master branch always reflects the most recent revision, and the git history is available. We could use tags to tag previous versions, or branches if there will be concurrent development on e.g. 2.x and 3.x.

chfast commented 6 years ago

@lrettig I'm fine with using git tags and branches for this.

axic commented 6 years ago

I actually propose that the current version is revision 3, because it was mistakenly not bumped by #77. Proposed fix: #118.

As a result, I think we are currently discussion revision 4 for which I have created a Github project for tracking purposes.

Lastly, I have a feeling that going through each and every EEI method is a lengthy process and I hope we can sort out some of the smaller, but still breaking, changes listed in the revision 4 project. If that happens, then the meticulous review process will fit into revision 5 discussions.