stan-dev
RStan & expiring deprecations
Transferring the discussion from the forums for visibility.
We're approaching the expiration of deprecated syntax (e.g., arrays) before rstan is compatible with the new syntax and downstream packages can update. The current compromise is to delay the deprecations by a release cycle (four months), with the goal of having 2.26 (and then quickly 2.31/2.32) on CRAN in the near future so that downstream dependencies can begin to update.
We will also have the lee-way of an additional release cycle after the deprecations expire through the use of the stanc auto-formatter. But as mentioned, this will only work for one release cycle after the deprecations expire.
I personally think that this feasible, and am happy to handle most of the PRs patching downstream dependencies. But I'm not familiar enough with rstan's previous/current CRAN difficulties to know whether it's likely to get 2.26+ to CRAN soon, so feedback is appreciated
I personally think that this feasible, and am happy to handle most of the PRs patching downstream dependencies. But I'm not familiar enough with rstan's previous/current CRAN difficulties to know whether it's likely to get 2.26+ to CRAN soon, so feedback is appreciated
Thanks @andrjohns. @bgoodri thoughts on the 2.26+ timeline?
I followed up with the remaining maintainers from #1053 by email and now only four packages have yet to merge the fixes for their package on Github - three of those (beanz, idem, and visit) also belong to a single maintainer
@bgoodri Can the StanHeaders submission be made now? I don't believe there's anything more we can do for the downstream packages, but feel free to correct me
@bgoodri Feels like I'm shouting into the void here, but there are now only four downstream breakages (from two maintainers) under all combinations of 2.21, 2.26, and 2.31 rstan/StanHeaders. These maintainers haven't responded to the PRs or direct email.
Do with that what you will. Or don't. Ball's in your court.
