Version specs or officially finalize them and make them immutable
uint opened this issue · comments
Do one of these:
- Version specs
- Officially finalize them and make them immutable
I vote 2.
Why?
Changing specs can cause problems down the line.
An argument could be made that adding an optional field to a cw20 msg is no problem since the change is "backwards compatible". I understand that POV, but this can still cause complications.
Example problem scenario
We add an optional emoji field to cw20::ExecuteMsg::Send. This is backwards compatible - the contract will still accept the old format of messages from old clients, with no 🥷🏼. Cool.
But realistically, there will now be contracts out there which accept an emoji, and contracts which never upgraded to the new spec.
In comes Bob. Bob develops a cw20 wallet, diligently using the cw20 specification in its current format. There's no clear information for Bob that the emoji field didn't exist a few months ago, so he happily gives end users the option to include emoji. The protocol supports that, after all.
Bob's wallet seems production-ready. It passes tests against cw20-base - our exemplary implementation of cw20! A few people have used it with success. Awesome.
Bob's wallet gets released. More people start using it. And out of nowhere reports start pouring in that when those emoji-loving people try to send some specific tokens, a cryptic and frustrating deserialization error happens. "Unknown field" - what does that even mean?
Let's do 2.
Following Ethereum, specs are immutable. If you don't like erc20, you invent a new one (say erc777) which may or may not be somewhat "backwards compatible", but it has a clearly different number saying "if you try doing some compatibility, you must be careful and handle multiple cases"
Following up on this in #832