chore: add two new upgrade examples + refactor existing ones
Depends on #2342
cc @jeronimoalbi
I really like the approach taken in upgrade_e and upgrade_f, they are elegant and idiomatic 👍
I'm wondering if it makes sense to eventually have another upgrade example case, where the "home" realm is actually versioned using v1, v2, and so on in the realm path for major versions, where the inner interface implementations from upgrade_e are considered minor versions. If this makes sense, it would allow "home" to eventually be bumped up to a new major version when any public realm functions or the interface changes.
I'm wondering if it makes sense to eventually have another upgrade example case, where the "home" realm is actually versioned using v1, v2, and so on in the realm path for major versions, where the inner interface implementations from upgrade_e are considered minor versions. If this makes sense, it would allow "home" to eventually be bumped up to a new major version when any public realm functions or the interface changes.
To be tried!
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 55.00%. Comparing base (
b1c1c96) to head (85556b9). Report is 1 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #2334 +/- ##
==========================================
- Coverage 55.01% 55.00% -0.01%
==========================================
Files 595 595
Lines 79765 79792 +27
==========================================
+ Hits 43880 43890 +10
- Misses 32567 32584 +17
Partials 3318 3318
| Flag | Coverage Δ | |
|---|---|---|
| gno.land | 64.15% <ø> (+0.01%) |
:arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.