Deprecate ggplot functions in future rstan?

[jgabry]

@bgoodri @andrjohns @hsbadr Should we deprecate all the ggplot functions in rstan? Maybe in conjunction with the release of 2.26 or another future version? The ggplot functions in rstan were added before bayesplot existed and I'm not sure if there's any reason to keep supporting both. We could deprecate and point users to bayesplot. Thoughts?

[bob-carpenter]

how have CRAN normally been for rstan releases? Much of a battle?

There's a reason there hasn't been a new RStan release in years. I believe the choke point is lack of dependency management in CRAN. Without that, Stan's policy of not maintaining low-level backward compatibility of internals has made it impossible to get a new release out that is compatible with old and new versions of Stan, which would be needed to release without pinning dependency versions.

[andrjohns]

We've actually got all of that in place for 2.26 and then 2.31 (sans ~10-15 packages yet to merge and release patches I've submitted), it's just a matter of the actual submission now and whether that's enough notice to maintainers for CRAN to accept breaking their packages

[hsbadr]

Does that mean it could be a matter of days (rather than weeks, months, etc.) for RStan 2.26? Or would you expect it to still be further off

This is a good question for @bgoodri :)

He could submit it now and provide notes to justify the failed dependencies.

There's a reason there hasn't been a new RStan release in years.

Originally, dozens of packages failed until we implemented Stan/Math patches for backward compatibility and notified the package maintainers about the required changes (and even submitted PRs to fix them) months or years in advance. CRAN is ok with the notices alone, and we've already fixed the majority of dependencies. Only two packages fail now with segfault due to the incompatibility of the new StanHeaders and the old rstan (precompiled with different headers). This is a circular dependency.