Contract versioning doc

[nialexsan]

Closes: #???

Description

contract versioning strategy and some suggestions

---

For contributor use:

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the standards mentioned here.
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[jordanschalm]

Thanks for the writeup

[jordanschalm]

This pattern adds globally mutable, non-type-safe state, which makes our code more difficult to understand and reason about, and increases the likelihood of bugs.

I would like to frame this pattern as a way to temporarily implement changes in a prior, deployed version in a upgrade-compatible way, only when strictly necessary. We should never use this pattern on the main branch, and should try to avoid it in general.

[nialexsan]

agree, this is a temporary measure to implement missing behavior in already deployed contracts, and with a newer version these changes should be implemented with proper typing.

I still think it's still useful to have this escape hatch in the main branch to keep the contracts extendable and don't forget to add this field just before the deployment

[jordanschalm]

👍 agree, "never use" as in "the container is empty and not referenced", not "the container doesn't exist"

[Kay-Zee]

with the same name

[Kay-Zee]

do we need to describe or indicate anything about contract naming on these branches? do we want to have any rulesets for that?

[nialexsan]

added a section regarding contract naming