Planning the 2.32 release

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.

4 Likes

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.

1 Like

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

We should fix this normal_lcdf and normal_lccdf give infinite gradients for infinite inputs. · Issue #2881 · stan-dev/math · GitHub as well.

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

I added a stanc3 issue Expose `hypergeometric_2F1` and `hypergeometric_3F2` · Issue #1285 · stan-dev/stanc3 · GitHub

3 Likes

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

1 Like

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.

1 Like

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)

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.

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

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

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

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

1 Like