Planning the 2.36 release

Developers
1

Since 2.35 was released on June 3rd, the four month release cycle takes us to the end of next month (September). I think it also makes sense to give an extra week or so due to StanCon Oxford taking place next month.

I am proposing the following dates:

  • Feature freeze on Monday, September 30th
  • Release on Monday, October 7th

As always, please use this thread if you have any thoughts on those dates, or if you need a pull request reviewed or think an issue is a high priority for this release.

3 Likes
2

sounds good to me. I’ve got some PRs about adding improved R-hat and ESS that need add’l work in order to get in for the next release - Feature/3299 improve ess mcse by mitzimorris · Pull Request #3305 · stan-dev/stan · GitHub et al

1 Like
3

Bumping this for visibility post-StanCon

3 Likes
4

Tracking issue is up at Release CmdStan 2.36 · Issue #1296 · stan-dev/cmdstan · GitHub

3 Likes
5

For those keeping track, the feature freeze and subsequent release will almost certainly delayed while we pursue resolutions to Compilation failures under LLVM 19 · Issue #3106 · stan-dev/math · GitHub

This may involve a fair amount of work (possibly creating our own implementation of complex numbers stan::math and std::complex · Issue #3006 · stan-dev/math · GitHub) so it’s too early to give a new estimate for when the release would be

6

The above linked issue is resolved, but we want to take some time to look into a more complete solution to the issues that have been arising with std::complex support (3 out of the last 4 LLVM releases have broken stan-math because of these)

@stevebronder thinks this would be reasonable to do in a month’s time, so I’m proposing the following new timeline:

  • Feature freeze on November 4th, 2024
  • Release on November 11th, 2024
5 Likes
7

@stevebronder do you think we can get in the unit_vector repulsion thing for this release?

8

I think this would be next release.

9

I would very much appreciate this - I would love to see the rank-normalized rhat, ess for CmdStan go in and there’s a few things to nail down w/r/t Feature/3299 diagnostics chainset by mitzimorris · Pull Request #3310 · stan-dev/stan · GitHub and Feature/1263 update stansummary to report rank-normalized ESS tail, ESS bulk, max abs deviation(MAD), and Rhat by mitzimorris · Pull Request #1290 · stan-dev/cmdstan · GitHub

2 Likes
10

@stevebronder and I ran into some unexpected difficulties. With the hope of not needing another Math Library major version bump next release, we’re going to delay this another 3 weeks (RCs on 11/25).

If we can’t come up with a solution by then, we will likely proceed with the release as-is, and try to fix these issues more completely next release

11

Here are the PRs that should be merged in the next week before the RCs (roughly in priority order):

12

Can’t wait for this release! Thanks @WardBrian for putting these together

2 Likes
13

All of the above linked PRs are merged, so unless something comes up in the next couple days we’ll proceed with the RCs next week. The release will be two weeks later (assuming no issues), to avoid any conflicts with the Thanksgiving holiday in the US

5 Likes
14

RCs are now out!

5 Likes
15

This is great, thank you!

I tried the release candidate and noticed several of my models failing with the error message “The jacobian adjustment can only be applied in the transformed parameters block or in functions ending with _jacobian” which looks like it arises in stanc3 here. Are there migration notes available?

Here’s an example from the Gaussian process inference library we’ve been working on.

ValueError: Failed to get source info for Stan model '/home/runner/work/gptools/gptools/stan/docs/logistic_regression/logistic_regression.stan'. Console:
Semantic error in '/home/runner/work/gptools/gptools/stan/gptools/stan/gptools/fft1.stan', line 97, column 32, included from
'/home/runner/work/gptools/gptools/stan/docs/logistic_regression/logistic_regression.stan', line 3, column 4:
   -------------------------------------------------
    95:      int nrfft = n %/% 2 + 1;
    96:      vector[n] z = gp_rfft(y, loc, cov_rfft);
    97:      return std_normal_lpdf(z) + gp_rfft_log_abs_det_jacobian(cov_rfft, n);
                                         ^
    98:  }
    99:  
   -------------------------------------------------

The jacobian adjustment can only be applied in the transformed parameters block or in functions ending with _jacobian

The GitHub Action run is here, the model is here, and the offending line is here.

2 Likes
16

Huh, we took care to implement jacobian += in such a way old usages (e.g., if the user had a variable called ‘jacobian’) would still work, but I think functions ending in _jacobian slipped our mind. It looks like you’re not the only ones who would be affected.

We will have to find something backward compatible/issue warnings for a couple versions. Thanks @tillahoffmann

4 Likes
17

How about variable names ending _jacobian? (ie, not just jacobian)

18

Those are still fine (after all, you can have a variable ending in _lp)

19

@tillahoffmann we will do an RC2 next week, but if you want to test the fix in the mean time, you can snag one of the executables from Release nightly · stan-dev/stanc3 · GitHub and drop it in cmdstan/bin/stanc

The old model should still compile, though it will raise a warning about the future change in behavior

3 Likes