Planning the 2.29 release

Developers
1

Hi all,

the Stan 2.29 release is about a month away based on our release schedule. We had two patch releases for the 2.28 release, so the last release was actually on the 5th of November.

I am opening this thread as there are a few things we need to discuss before the release and this is also an opportunity for everyone to ask for any reviews that they have been waiting for too long. If you are planning on working on any new features that you would like to propose for 2.29, please let us know, if you haven’t already. We would like to avoid pre-release stress as much as possible.

Release date:

I would propose doing the freeze on the 17th of January (which is a Monday) and then doing the release the next Wednesday (the 26th of January) at the earliest. This means prolonging the freeze for 2-3 days compared to our usual schedule. This gives us a bit more time to do proper RC testing. This was a bit of an issue the last few times around it seems (see the number of patch releases).

We are working on a more rigorous performance testing procedure that we will run with the RC, to search for any performance regressions before the actual release.

Patch releases are fine, bugs happen, but there were cases in the last few releases where there were things that got discovered basically within a day or two after the official release.

If no one comes forward with a counterproposal until the new year, this will be the release schedule. Happy to discuss and fine-tune, as always!

Feature list:

In the Math/Stan/CmdStan repos, this last cycle was mostly focused on bug fixing and improving the development experience and CI improvements.

A similar story for Stanc3, where we addressed quite a few minor bugs, exposed a few missing signatures, improved the developer experience by bumping the OCaml version (this does not affect Stan users), improved our CI and testing, moved the docker image to dockerhub, improved documentation.

We also improved user-facing error messaging, revamped auto-formatting and the canonicalizer and started with the deprecation process.

Deprecation:

The next release will be the first where we will start more actively warning users on deprecated features and also providing an end date in the warning messages. With 2.29, using some language features will give out warnings that they will be removed after a year (so in release 2.32).

Some of the features that will be removed in 2.32:

  • functions multiply_log, binomial_coefficient_log, cov_exp_quad, if_else, increment_log_prob, get_lp,
  • _log, _cdf_log, _ccdf_log suffixes for distributions,
  • used of distributions functions without the vertical bar after the first argument,
  • the # comment sign and <- assignment
  • some stanc3 flags like allow_undefined (in favor of allow-undefined)
  • the following keywords will not be allowed after 2.32: array , upper , lower , offset , multiplier
  • the old array syntax (int[], real[]) in favor of array[] int and array[] real

This last one will probably be the most notable one. Users will be able to automatically convert their models to using the new array syntax with stanc3. We are also working on a web interface to simplify updating to the new syntax. A work in progress on that can be found here. Eventually, this web app will probably be moved to the official Stan page (pending approval of other developers/SGB - official proposal for that is coming soon).

The old ODE functions are also marked for deprecation, but for the 3.0 release, which is still TBD and with no firm plans.

PR review request

I have two PRs open in CmdStan if anyone has time to take a look, I would appreciate it. Both of them are small bug fixes with minimal code changes: Fix #997: proper use of `std::setprecision` in `bin/diagnose` by rok-cesnovar · Pull Request #1067 · stan-dev/cmdstan · GitHub, Fix #1056 and #1013 by rok-cesnovar · Pull Request #1065 · stan-dev/cmdstan · GitHub

Please post below if you have any PRs waiting to be reviewed.

Thanks!

8 Likes
2

The only two open lines of development I have that could be nice for 2.29 are bug fixes -

  1. Fix issue with function shadowing by WardBrian · Pull Request #1011 · stan-dev/stanc3 · GitHub which is waiting on Stan::math and is pretty low priority (users can just not use those names for now, and I don’t think we’ve gotten any reports of it “in the wild”)
  2. Two PRs (1, 2) related to type promotion of complex types. This would be what fixes the current issue where you cannot pass e.g. integers to complex-valued functions, and also in theory give us the ability to pass array[] ints to array[] real functions, which would be great. @stevebronder and I need to collaborate on this in the new year, but I think we could get it sorted out in the 2-3 weeks before the freeze.

The main thing that needed to be in this release from a stanc perspective was the deprecation warnings and formatter changes, which should all be good to go

3 Likes
3

Do we plan to have CI moving done by the freeze?

4

We are hoping it will be yes. I have talked with Nic since the Math PR where we had CI issues, and we should be able to now run it on our old CI. I plan on taking a look at the failing teests in the next few days.

1 Like
5

I think we can, still have to iron out some dependencies in the Dockerfile used for CI, and then importing the jobs should go just fine. Will try to finish it earlier tho so we have a week or two of making sure it’s fine.

3 Likes
6

Is there a reason the CI move would need to be tied to a release cycle? Besides us getting to put thank yous in the release notes, it’s not a huge deal if we switch in the middle of the next cycle right?

7

I was asking because I have a couple of PRs coming and I’d like to avoid being caught in the middle of moving, in addition to that SGB would like to keep track of the process for the sake of cost planning.

8

A thousand thank you’s if this (couple of PRs coming) happens to be the DAE/IDAS PRs 😀🤞🙏 If at some point you want someone else to see if that works as you intend, we have a model ready to go that we already have in Stan and replicated in the C interface to IDA and could test it against your implementation if that helps

9

@yizhang totally understandable, my goal would be a seamless move without much disruption for the developers.
We need to also move the gelman instances we have in our current Jenkins over to Flatiron. Main reason is opencl cpu cl_khr_int64_base_atomics instruction is not supported on the Flatiron CPUs and we need gelman machines so we can run that part of the pipeline.
Now I can either do this next week, probably in the weekend when there’s not much CI going and hope to iron our all possible errors before the release candidate and the freeze or we can do it after the next release, wdyt ? Note that CI will be offline during this 1-2 day period.

10

I think if we do it once we get the release candidates out, that would be the best. The freeze period will be at least 10 days, so if we do it immediately after we push out the RCs, that should give us enough time.

1 Like
11

somewhat related to CI - release scripts - are these being migrated as well? cf this issue: colab-stan for version 2.28 · Issue #1068 · stan-dev/cmdstan · GitHub

the more general question is can we do pre-built distributions for various architectures?

12

@rok_cesnovar should we delay the release until the fix for index slicing is done? imo that’s a bug in the impl and if we do another release with it in there folks are going to start expected Stan to have reverse indexing. I can do that on Monday

1 Like
13

Sure, there are still 10 days until the freeze and then 10 days of the freeze Will keep up with that PR to check in on how it’s progressing.

1 Like
14

Hi, I just wanted to notify everyone that we are going to do the freeze a week later, on the 24th of January and then do the release on the 7th of February.

There are a few projects that are right at the finish line and we want to avoid stressing our developers to get all the features they have been working of for quite some time merged before the freeze. Given that the last patch release was done not even 2 months ago, I think we are in no hurry of doing it.

7 Likes
15

Here are the things I’ve been working on or reviewing that I think should make it at this point:

Edit: All three of these have been merged. The DAE doc is still in need of review, but otherwise I think everything I wanted to get in before the freeze is done

6 Likes
16

Any chance we can get these reviewed and in. I believe @andrjohns has finished them and they just need reviewed.

The first 3 will allow us to implement student_t copulas.

3 Likes
17

Hey! Are we waiting for the above PRs before the release candidate today? Is there something else on our plate that we need to merge in before? Thanks!

18

I think it’s too late for the above PRs since today’s the feature freeze, and they’re not bugfixes or blocking anything urgent.

Feel free to go ahead with the RC!

1 Like
19

Looks like we need to wait for Fix assign and lvalue to return 0 row/col/size objects for negative indexing by SteveBronder · Pull Request #3095 · stan-dev/stan · GitHub which may take until tomorrow.
See release checklist.

1 Like
20

I know you are very busy, but would it be possible also to update the repo for Google colab? The latest version is 2.23 and it’s been a while. I use Google colab + cmdstan for my teaching.

Thank you in advance

2 Likes