Discussion - Incompatibility and Upgrade Strategy for AVL between GitHub and test3.gno.land

[moul]

TL;DR

The AVL at https://test3.gno.land/p/demo/avl is incompatible with the AVL found at https://github.com/gnolang/gno/tree/master/examples/gno.land/p/demo/avl. Developers are currently forced to choose between using local tool support with the latest git updates or exclusively working by pushing contracts. These two approaches cannot be seamlessly integrated at the moment.

Context

Our focus is on creating a strong set of base libraries on GitHub, rather than relying on future features like unchanging dependencies in Gno.

In the future, we anticipate changes to the AVL package with new contract releases, such as test3.gno.land/p/demo/avlv2.

Upgrading import paths or sticking with the previous implementation will be possible. We expect versioning assistance from gno.mod or similar mechanisms.

While developing, concise import paths will be used, and upon publication, the import paths will contain the full version for clarity.

However, currently, these features are unavailable, and we want to avoid limiting or complicating the GitHub repository.

This discussion focuses on the upgrade strategy, using this specific example to address similar needs, especially on official testnets.

Proposed Solutions

Prop 1

Reset the whole blockchain, losing all state.

Dislike: Losing on-chain content and debugging information.

Prop 2

Release test4 (and potentially test5, 6, 7 frequently).

Dislike: Creates more confusion.

Prop 3

Implement a migration feature, specifically for testnets. Patch the contracts to rename avl to avlv1, ensuring dependencies reflect the change.

Like: Provides a migration solution, but may be overkill for testnets.

Prop 4

Upload avl again as avlv2 without patching the history. Users can manually import avlv2, but it creates a different codebase between local development and production.

Better than the second proposal, but not ideal.

-> Existing PR from @piux2 for the faucet: https://github.com/gnolang/gno/pull/956

Prop 5

Hardcode the contract patches based on GitHub. Use a migration script to override everything on GitHub without considering the impact on other contracts.

Favorite method: It may break things but not everything, and developers can manually re-upload contracts as v2 if they want them to be usable on test3.

---

Please provide your opinion and additional ideas for managing this case so we can make an informed decision.

Related: #694

TODO: add related issues, PRs

[moul]

Note from meeting:

• If we want to migrate packages, it's not only about patching source code, but also porting states
• another proposal we can do: p/ are immutable, r/ are upgradable
• support patchContract (append only, non-breaking updates)
• use gno.mod to support versioning
• we keep test3, upload new package avl/v2; test3.gno.land/p/demo/avl is not similar to github; people needs to change their import to avl/v2 of they want to publish on test3
• when launching test4, we remove avl/v1, and avl/v2 becomes avl
• mark as "latest" (stable) without deprecating the previous ones

other alternative:

• keep multiple versions on github: p/demo/ufmt and p/demo/ufmt/v2 in the master branch

overall strategy, or only for packages exposing useful structs.

• we want to make breaking changes on p/ something
• it's okay to publish v2 manually, let the v1 becoming unsynched from github
• we let developers to patch their import paths before publishing on outdated testnets
• and we focus on having a single github version of each package, without version in paths, targeting the upcoming mainnet

[ajnavarro]

when launching test4, we remove avl/v1, and avl/v2 becomes avl

If test4 won't be a new chain, that might cause several problems, right? Like, some realms will still be depending on avl or avl/v1, causing execution errors.

What is the problem with keeping versions as they are, even if before launching mainnet we have an avl/v3 or v4?

[moul]

Once launched, the new chain, test4, will simply follow the GitHub tree, which doesn't incorporate any versioning. The phrase "we remove" actually implies a lack of action.