split release versions of bins and libs

[tzemanovic]

Describe your changes

• crates/apps will be versioned separately from everything else, starting at v1.0
  • tagged v1.0.0
  • maintenance branch maint-1.0
  • released with scripts/release_bins.sh
  • apps may be preceded by libs release with the libs release backported to the apps maintenance branch
• everything else will continue with the current versioning scheme, currently at v0.46.0
  • the tags will be prefixed with libs-, e.g. next patch release tag would be libs-v.46.1
  • maintenance branch at maint-libs-0.46
  • released with scripts/release_libs.sh
  • libs can be released independently of apps at any time
• what about changelogs?
  • both kinds of releases will be appended to the CHANGELOG.md in their release order and the libs release versions will be prefixed with libs- to distinguish them
  • most apps releases will usually have their changes coming from the libs, their changelog may often only contain e.g. updated namada libraries to libs-vX.Y.Z
• backporting PRs
  • we can use labels backport-lib-X.Y for libs and backport-X.Y for apps
  • the vast majority of backporting PRs will only be touching libs as the crates/apps is a very thin layer of main fns which dispatch most of their functionality to crates/apps_lib
    • but if you need to modify both libs and apps with a non-breaking change, tag it with both labels

Updated release process

• patch releases (non-breaking changes)
  • release from maintenance branches
  • libs: after release merge the maintenance branch back to main
  • apps:
    • if we need changes from libs, merge the needed libs tagged release libs-vX.Y.Z into apps maint branch before release (never merge unreleased libs branches here, such as a libs maintenance branch)
      • with this we should add a changelog updated namada libraries to libs-vX.Y.Z to serve as a link to the change set from libs
    • merge after release to main and then merge main into latest maint-libs-X.Y
• minor releases (breaking changes)
  • if we're releasing both libs and apps at the same time, libs should be released first
  • always release from the main branch
  • libs: after release create a new maintenance branch maint-libs-X.Y
  • apps:
    • before release, if libs version has changed from the last apps release, also add a changelog updated namada libraries to libs-vX.Y.Z to serve as a link to the change set from libs
    • after release create a new maintenance branch maint-X.Y

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies:

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.58%. Comparing base (c61bbe0) to head (63dae40).
Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4117   +/-   ##
=======================================
  Coverage   74.58%   74.58%           
=======================================
  Files         341      341           
  Lines      107491   107491           
=======================================
+ Hits        80169    80170    +1     
+ Misses      27322    27321    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.