# Planning the 2.32 release

**URL:** <https://discourse.mc-stan.org/t/planning-the-2-32-release/30641>\
**Category:** Developers\
**Created:** [March 6, 2023, 6:10pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641 "2023-03-06T18:10:15Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [March 6, 2023, 6:10pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/1 "2023-03-06T18:10:15Z")

</div>

Just wanted to give a heads-up on the plan for the next release - version 2.32  
The proposed plan is:

- the feature freeze on the 4th of April,
- the official release on the 17th of April.

Please let me know if you think any of these dates should be moved. We are pretty flexible this time around, barring any surprises, this should be a pretty minor release.

If you need a pull request reviewed or think a bug fix is a high priority for this release, please use this thread to report it.

---

<div class="post-metadata">

**Author:** ![jsocolar](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jsocolar/32/2486_2.png) [@jsocolar](https://discourse.mc-stan.org/u/jsocolar)\
**Post date:** [March 6, 2023, 7:31pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/2 "2023-03-06T19:31:23Z")

</div>

Just want to double check: is 2.32 going ahead with removal of the deprecated array syntax? If so, it’d be worth thinking of this as a major release in terms of its impact on the community. e.g.

> <https://github.com/paul-buerkner/brms/issues/1376>
>
> The current version of \`stanc3\` generates the following warning:
> \`\`\`
> Warning: …Declaration of arrays by placing brackets after a type is deprecated
> and will be removed in Stan 2.32.0.
> Instead use the array keyword before the type.
> This can be changed automatically using the auto-format flag to stanc.
> \`\`\`
> 
> For example, \`int\[\] y\` becomes \`array\[\] int y\`.

---

<div class="post-metadata">

**Author:** ![spinkney](https://avatars.discourse-cdn.com/v4/letter/s/dec6dc/32.png) [@spinkney](https://discourse.mc-stan.org/u/spinkney)\
**Post date:** [March 6, 2023, 7:49pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/3 "2023-03-06T19:49:27Z")

</div>

I’m hoping a bunch of things can get finished in Stan math

- [[BUGFIX] grad\_2f1: Add minimum number of iterations and early stopping test by andrjohns · Pull Request #2858 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/2858)
- [Feature/issue 2682 add 7 parameter ddm pdf by Franzi2114 · Pull Request #2822 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/2822)
- [Fix weibull lcdf by spinkney · Pull Request #2811 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/2811) (I don’t know how to resolve the opencl issue)
- [https://github.com/stan-dev/math/pull/2642](https://github.com/stan-dev/math/pull/2642)

We should fix this [normal\_lcdf and normal\_lccdf give infinite gradients for infinite inputs. · Issue #2881 · stan-dev/math · GitHub](https://github.com/stan-dev/math/issues/2881) as well.

Let’s get the hypergeometric functions exposed in Stan b/c these are merged

- [https://github.com/stan-dev/math/pull/2792](https://github.com/stan-dev/math/pull/2792)
- [Expose `hypergeometric_3F2` function by andrjohns · Pull Request #2797 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/2797)

I added a `stanc3` issue [Expose `hypergeometric_2F1` and `hypergeometric_3F2` · Issue #1285 · stan-dev/stanc3 · GitHub](https://github.com/stan-dev/stanc3/issues/1285)

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 7, 2023, 2:12am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/4 "2023-03-07T02:12:16Z")

</div>

> [@jsocolar](#):
>
> is 2.32 going ahead with removal of the deprecated array syntax

I’m working on the PR which will formalize this now, but yes, that is currently the plan. For 2.32, the expiring deprecations will become errors, but will still be parseable and `--auto-format`’s `--canonicalize=deprecations` will recognize them and produce the updated syntax.

For 2.33 and on, they will not be recognized at all. It’s looking like Tuples will finally be able to land in 2.33, and they are really reliant on the new array syntax, so a delay in the deprecation schedule could start holding up features. If there are things we can do to make this less painful for the R packages I’d love to hear them

---

<div class="post-metadata">

**Author:** ![jsocolar](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jsocolar/32/2486_2.png) [@jsocolar](https://discourse.mc-stan.org/u/jsocolar)\
**Post date:** [March 7, 2023, 3:04am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/5 "2023-03-07T03:04:10Z")

</div>

Tagging @paul.buerkner, as `brms` is by far the most prominent R package that depends on running Stan code via both `cmdstan` and CRAN’s `rstan`. Edit: the only strict dependency is on CRAN’s rstan, but running via cmdstan is important functionality.

If Paul feels good about the way forward, then I’m happy.

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [March 7, 2023, 7:50am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/6 "2023-03-07T07:50:28Z")

</div>

Is it planned that the auto-formatter will be able to digest the old Stan code with 2.33 and onwards?

I’d guess that as long as all this means is to switch on some parser option, then it’s manageable. In case the old syntax cannot be parsed at all with 2.33 going forward, then that could be an issue, I guess.

(great to read implicitly that tuples are going to land in 2023 presumably)

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 7, 2023, 1:19pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/7 "2023-03-07T13:19:08Z")

</div>

The plan is that in 2.33, the compiler can forget about the old syntax entirely. If the goal of deprecations is to allow the language and compiler code base to evolve, freezing the auto formatter would prevent us from actually deleting that old code.

Of course, if you have code from 2.19 or whatever version before 2.33, you can run the auto formatter from an “old” version (e.g. 2.31) as part of your update cycle and that will always work. It might be reasonable to provide a really striped down binary which only does migration of pre-2.33 code (e.g. not even compilation), since that binary would never really need to be updated.

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 8, 2023, 9:56pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/8 "2023-03-08T21:56:45Z")

</div>

For things I would like to see merged before the release:

- Turn expiring deprecations into errors: [[Stan 2.32] Make expiring deprecations into errors by WardBrian · Pull Request #1287 · stan-dev/stanc3 · GitHub](https://github.com/stan-dev/stanc3/pull/1287) - superceeded by [[Stan 2.32] Delay expiring syntax deprecations one version by WardBrian · Pull Request #1303 · stan-dev/stanc3 · GitHub](https://github.com/stan-dev/stanc3/pull/1303)
- Eigen 3.4 update: [[WIP] Update to Eigen 3.4 by SteveBronder · Pull Request #2583 · stan-dev/math · GitHub](https://github.com/stan-dev/math/pull/2583) - this is having a new out-of-memory in the Windows github actions runners, but otherwise should be done
- Update `get_dims` and `get_param_names`: [Add flags to get\_dims and get\_param\_names by WardBrian · Pull Request #1245 · stan-dev/stanc3 · GitHub](https://github.com/stan-dev/stanc3/pull/1245) and [Extend `get_dims` and `get_param_names` in model\_base by WardBrian · Pull Request #3139 · stan-dev/stan · GitHub](https://github.com/stan-dev/stan/pull/3139) - @rok_cesnovar is reviewing them both currently
- Tweak JSON handling of zero-size containers: [Relax requirements for 0-sized data objects in JSON by WardBrian · Pull Request #3170 · stan-dev/stan · GitHub](https://github.com/stan-dev/stan/pull/3170)
- Add ability to filter output in `stansummary`: [Add argument to only output some parameters from `stansummary` by WardBrian · Pull Request #1143 · stan-dev/cmdstan · GitHub](https://github.com/stan-dev/cmdstan/pull/1143)

---

<div class="post-metadata">

**Author:** ![Franzi](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/franzi/32/13476_2.png) [@Franzi](https://discourse.mc-stan.org/u/Franzi)\
**Post date:** [March 17, 2023, 9:55am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/9 "2023-03-17T09:55:37Z")

</div>

> [@spinkney](#):
>
> Feature/issue 2682 add 7 parameter ddm pdf by Franzi2114 · Pull Request #2822 · stan-dev/math · GitHub

Hey @spinkney, this sounds good! Is there anything else to do for me that helps finishing this PR until April?

---

<div class="post-metadata">

**Author:** ![avehtari](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/avehtari/32/5935_2.png) [@avehtari](https://discourse.mc-stan.org/u/avehtari)\
**Post date:** [March 20, 2023, 12:41pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/10 "2023-03-20T12:41:06Z")

</div>

> [@jsocolar](#):
>
> Just want to double check: is 2.32 going ahead with removal of the deprecated array syntax? If so, it’d be worth thinking of this as a major release in terms of its impact on the community

I predict we get a lot of problems if RStan in CRAN is not supporting new array syntax when the old syntax stops working in a new release. It would be good to be certain that there is a new working CRAN RStan before removing the old array support. Ping @bgoodri @andrjohns

---

<div class="post-metadata">

**Author:** ![spinkney](https://avatars.discourse-cdn.com/v4/letter/s/dec6dc/32.png) [@spinkney](https://discourse.mc-stan.org/u/spinkney)\
**Post date:** [March 20, 2023, 12:53pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/11 "2023-03-20T12:53:52Z")

</div>

I don’t think so. I know @andrjohns is reviewing your PR but he’s swamped with Rstan cran stuff.

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 28, 2023, 3:32pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/12 "2023-03-28T15:32:56Z")

</div>

> [@avehtari](#):
>
> I predict we get a lot of problems if RStan in CRAN is not supporting new array syntax when the old syntax stops working in a new release. It would be good to be certain that there is a new working CRAN RStan before removing the old array support. Ping

Before the freeze we need to either merge the PR which removes the deprecations or put together a new one which moves the removal versions back, so if we are deviating from the deprecation schedule it needs to be an active choice made soon. I’m not sure what the status of CRAN submission is, last I heard it was close (@andrjohns @hsbadr)

---

<div class="post-metadata">

**Author:** ![andrjohns](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/andrjohns/32/15297_2.png) [@andrjohns](https://discourse.mc-stan.org/u/andrjohns)\
**Post date:** [March 29, 2023, 6:13am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/13 "2023-03-29T06:13:03Z")

</div>

I believe 2.26 should be ready and there is only one package which will additionally fail under 2.31 (but they have a patch submitted which should be out to CRAN soon).

But @bgoodri is handling submission, so will let him clarify

---

<div class="post-metadata">

**Author:** ![andrjohns](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/andrjohns/32/15297_2.png) [@andrjohns](https://discourse.mc-stan.org/u/andrjohns)\
**Post date:** [March 29, 2023, 9:28am UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/14 "2023-03-29T09:28:21Z")

</div>

I’ve also consolidated the current status of `rstan` downstream package failures/patches here: [RStan & StanHeaders Downstream Patching Status · Issue #1053 · stan-dev/rstan · GitHub](https://github.com/stan-dev/rstan/issues/1053)

---

<div class="post-metadata">

**Author:** ![andrjohns](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/andrjohns/32/15297_2.png) [@andrjohns](https://discourse.mc-stan.org/u/andrjohns)\
**Post date:** [March 30, 2023, 12:03pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/15 "2023-03-30T12:03:41Z")

</div>

There are now no additional failures under 2.31, so once `StanHeaders` 2.26 and `rstan` 2.26 are on CRAN, the upgrade process should be painless.

Given this (assuming a CRAN submission for 2.26 soon), one option could be to push the deprecation removals back one more version. Then `rstan` users will have roughly a release cycle to prepare - and we’ll have the same to prepare downstream packages.

On that note, would it be difficult to build a `stanc.js` where the deprecations are errors? Then I can run the reverse-dependency checks and see what patches are needed

EDIT: Never mind about the `stanc.js`, I didn’t think to just pull it from the [PR](https://github.com/stan-dev/stanc3/pull/1287)

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 30, 2023, 12:37pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/16 "2023-03-30T12:37:56Z")

</div>

I recently did a check of our own CI to make sure none of the Stan or CmdStan test models would fail, so I have a Jenkins run with artifacts here: [Artifacts of stanc3-test-binaries #25 : /bin [Jenkins]](https://jenkins.flatironinstitute.org/job/Stan/job/stanc3-test-binaries/25/artifact/bin/)

---

<div class="post-metadata">

**Author:** ![andrjohns](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/andrjohns/32/15297_2.png) [@andrjohns](https://discourse.mc-stan.org/u/andrjohns)\
**Post date:** [March 30, 2023, 1:10pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/17 "2023-03-30T13:10:47Z")

</div>

Looks like the downstream failures are pretty extensive with the deprecations-as-errors, but I’ve suggested using the auto-formatter during the package installation as an interim solution: [Auto-format Stan models during rstan\_config()? · Issue #113 · stan-dev/rstantools · GitHub](https://github.com/stan-dev/rstantools/issues/113)

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 30, 2023, 1:27pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/18 "2023-03-30T13:27:48Z")

</div>

> [@andrjohns](#):
>
> I’ve suggested using the auto-formatter during the package installation

That will only work for 1 version post-removal, so it’s not the best long-term solution. At some point the .stan files themselves will need to be updated on disk, not just during parsing.

---

<div class="post-metadata">

**Author:** ![andrjohns](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/andrjohns/32/15297_2.png) [@andrjohns](https://discourse.mc-stan.org/u/andrjohns)\
**Post date:** [March 30, 2023, 1:44pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/19 "2023-03-30T13:44:42Z")

</div>

Is it necessary to remove that functionality from the auto-formatter? It could be useful for users in the same way that it has been for deprecated syntax.

Not that I’m advocating for this as a long-term solution in any way - I wouldn’t want it to be in place for more than a version anyway, otherwise we’re promoting/enabling incorrect syntax

---

<div class="post-metadata">

**Author:** ![WardBrian](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wardbrian/32/12078_2.png) [@WardBrian](https://discourse.mc-stan.org/u/WardBrian)\
**Post date:** [March 30, 2023, 2:54pm UTC](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641/20 "2023-03-30T14:54:50Z")

</div>

If the point of the deprecation policy was to improve the codebase, then yes it is necessary. The code the compiler is required to carry around to parse the old syntax is the same whether we’re auto-formatting it or compiling it down to C++, so we can’t actually move on until it is really gone.

We’re not going to be intentionally mean about this, so things which are “cheap” to update (e.g., turning multiply\_log into lmultiply) might stick around longer or even forever, but we only **guarantee** it for one version.

If you know that the source code you’re dealing with is 100% old syntax, there’s no reason you couldn’t use a 2.31/2.32 compiler to do the update forever into the future, but if you’re not careful with enforcing the deprecation policy it’s easy to imagine a year from now someone will try to write code which uses e.g. a new function from 2.33 with the old array syntax, and suddenly there’s no compiler that exists which can handle both those things.

[Next page](https://discourse.mc-stan.org/t/planning-the-2-32-release/30641.md?page=2)