Breaking changes lifecycle management

[dgkf]

It's been a few months in the making, but we finally had our one-day developer event where we settled some long-standing design decisions and aligned on a future direction!

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

Context

These design decisions are not ones that any single contributor could make on their own. They required a convergence of ideas, a re-alignment of goals and a redistribution of features among our package landscape. This included breaking changes - either in the scope of the package and user-facing API.

This includes

• the scope of what is currently {riskmetric}, no longer supporting "scoring"
• {riskmetric}'s instead unifying as atomic (notably, serializable-to- and from dcf) values
• Changing the default behaviors of user-facing assessment tools to be "no guessing" by default (and maybe foregoing any looser API)
• Internally considering the transition to S7, meaning extensions would break

Question

How do we want to manage breaking changes? Some non-exhaustive proposals might include:

• All new packages (and frankly, this might be the easiest path and allow us a more coherent branding across tools)
• Major version bump
• Retain backwards compatibility, just introduce new APIs and slowly deprecate old
• Other strategy?

[llrs-roche]

Maybe others know the usage of riskmetric internally on companies but on Posit's CRAN mirror it has close to 20 downloads daily, around . To keep existing users I would suggest a major version bump to riskmetrics and riskassessment. I don't think other packages have had much adoption that would require this signaling. A deprecation process might be needed in coordination with a major version bump.