Explore a better way to manage the library chart dependency tree

How should we manage library chart versions?

• Today, we use relative paths file://../rstudio-library to reference the library chart.
  • This allows us to deploy a library chart change and an application change at the same time.
  • This is nice, because we do not have to "deploy library chart change" and ensure that the repo is updated
  • THEN deploy the app change
  • It also makes testing easier
  • HOWEVER - for every library chart change, we must force all other charts to update version as well
• If we use a repository definition, rstudio-library gets freedom to version-float, and product charts can decide when to upgrade
  • potentially some issues with testing and making sure the library chart works...
  • any patches would need to become independent PRs

We originally made the first choice for velocity. As things have stabilized, I would like to avoid PRs like #199 where we have to add 3-4 files x 4 child charts = 16 files just because the library chart changed a version. It is tricky to keep track of. I lean towards the latter approach now, and maybe building helpers to make testing the library chart easier (#203 ) 🙈

Start by reviewing the library chart references across the product charts and compare the current relative-path approach with repository-based definitions. Read issues #199 and #203 for the version-update and testing context. Done means documenting and agreeing on a dependency-management approach that reduces unnecessary chart updates while preserving reliable library-chart testing.